The Napkin Representation
aa at astro.ex.ac.uk
Tue Jul 3 08:06:30 PDT 2007
Roy Williams wrote:
> Silvia Dalla wrote:
>> 2. The simplest time series table consists of 2 columns only: one
>> giving the time and one giving the observable that is varying in
>> 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".
>> Or can the representation describe more complicated time series
>> that have a time column and several columns for different
> As you know, the wider the scope of any standard, the more
> difficult it is to reach agreement. Thus, for the moment, the
> discussion has been about the simple case above.
I would say that the current napkin representation could easily have
multiple magnitude/flux values (and uncertainties) for each time
<Time units="s" uncertainty="0.5">0/Time>
<Flux type="mag" band="R" uncertainty="0.01">13.2</Flux>
<Flux type="mag" band="B" uncertainty="0.02">17.4</Flux>
<Time units="s" uncertainty="0.5">35/Time>
<Flux type="mag" band="R" uncertainty="0.01">13.3</Flux>
<Flux type="mag" band="B" uncertainty="0.02">17.5</Flux>
in one of out suggested representations.
> In addition to flux, I have seen light-curves that include an
> attribute called "seeing", but that is still only two independent
Hadn't realised that people wanted that, when was this mentioned?
Is a seeing measurement for every time step really necessary (i.e.
for each row)? or only per time-series, in which case it would easily
be fitted into a <Param /> inside the <Meta /> block. Of course you
could generalise the params and allow them to get inserted inside a
<Row /> but at that point we've just reinvented <VOTable> and we
should probably forget about it. This is, at least for me, about
getting properly marked up light curves into my event data.
> Many people prefer a more rigid schema than VOTable provides, a
> more pure XML model.
More information about the dm