The Napkin Representation (fwd)

Silvia Dalla s.dalla at manchester.ac.uk
Tue Jul 3 09:34:46 PDT 2007


cc-ing to the VOEvent list too.

---------- Forwarded message ----------
Date: Tue, 3 Jul 2007 16:23:37 +0100 (BST)
From: Anita M. S. Richards <a.m.s.richards at manchester.ac.uk>
To: Roy Williams <roy at cacr.caltech.edu>
Cc: Silvia Dalla <s.dalla at manchester.ac.uk>, DM Mailing List <dm at ivoa.net>
Subject: Re: The Napkin Representation



Silvia, Roy et al.,

It seems to me that there are two approaches here - one from the point of view
of people interested mainly in the time domain behaviour of variable or
erruptive sources, or of data (e.g. Solar) where the viewpoiint changes as a
function of time.  The other aspect is those of us who are venturing into the
time domain as high angular resolution or sensitivity reveals variability or
allows us to study it - alongside other multi-wavelength properties.  That's
what I am more familiar with, and variability is usually a different function of
time at different wavelengths - the sort of thing that the Characterisation
model should be able to cope with for calibrated data.

>
> > 2. The simplest time series table consists of 2 columns only: one
> > giving the time and one giving the observable that is varying in time.
> > Is the new representation aimed only at this very simple time series?
>
> The motivation above would mean that the observable is a photon flux through a
> given transmission filter, expressed as magnitude or Jansky. So the current
> target is not about the general "time series", but rather about the much more
> specific "light curve".

Two issues - if we are allowing magnitudes, can we also allow X-ray counts? (I
would like to see all data calibrated in physical units, but it ain't, and for
the history of variable objects, when there are very few X-ray telescopes, we
ahve to take what we can get).

Secondly, typically I want to label data with the waveband (radio) and with the
observing wavelength or wavelength interval (or better still frequency, but
that's not important) - there might be several observations at one wavelength
and several at another.  Would this have to be in separate data sets with the
wavelength information in a header-type structure, or in a 3rd column?  If in a
header-type structure, i.e. keepinf 2 columns only, then it is even more
important to maintain a header structure which existing VO tools of all kinds
will recognise.
> > 
> > For those that were not at the HTN meeting it would be useful to know
> > what are the objections against using a VOtable representation.
> Many people prefer a more rigid schema than VOTable provides, a more pure XML
> model. But I do not see VOTable as a necessary part of a standard, it is just
> a representation. It is the names of quantities and what they mean, that is
> the important part.

I am very very wary of additional formats; this has been suggested be fore but
the beauty of VOTable is precisely that it is very simple and the average
astronomer in the wild can get to grips with it, whereas the full complexity of
XML scares us off.  More imporantly, VOTable is so widely used that there are
many tools in both astronomy adn solar physics which use it.  For example, one
of the students here has just written a package to raid the MERLIN archive for
all data on X-ray binaries, process the data with parselTongue, and convert the
output to a VOTable of variability (flux density v. time at various frequencies)
which can then be merged or compared with variability data from other
observatories. The point is, that this is not someone starting with the
intention of using VO tools, it is someone who happens to find them more useful
that the alternatives, since VOTables are more likely than any other format to
be produced by the other data providers and recognised by the tools he wants to
use... so he is surely not the only one.

Any format can be used within an observatory, etc., but whilst Roy is
technically correct to say
> Think of translating base 2 numbers to base 10, it is easy to do, it is just
> representation.
in practice, - as he said earlier - every extra bit of complication is another
pain in the posterior and a deterent to the casual user to string another
command in their workflow - and more seriously, every format conversion is
another opportunity to lose metadata.

So, I would argue that any format in which data are published should be
intelligible to tools which handle VOTables, without any special extra tools,
and that all the essential metadata defined in IVOA standards is preserved in
the VOTables.

best wishes

Anita

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank
Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572683
(direct); 571321 (switchboard); 571618 (fax).




More information about the voevent mailing list