The Napkin Representation

[Alasdair Allan]

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  
>> 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".

Yes.

>> Or can the representation describe more complicated time series  
>> tables
>> that have a time column and several columns for different  
>> observables?
>
> 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  
stamp, e.g.

  <Data>
     <Row number="1">
        <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>
     </Row>
     <Row number="2">
        <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>
     </Row>
       .
       .
       .
</Data>

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  
> variables.

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.

Yup!

Cheers,
Al.