[nvo-techwg] Time series data

[Rob Seaman]

Hola,

So Doug says time series demand a standard VO-wide data model:

>> Hence, at least for spectra (and probably also for time series),  
>> general multi-wavelength analysis requires mediation to a standard  
>> data model.

And Arnold seems to assert that STC should provide that standard:

> I put together an example that encodes the complete information  
> from IAUC 8653 in an STC-compatible WhereWhen - if only it would  
> allow multiple instances of ObsDataLocation (or, alternatively,  
> multiple instances of WhereWhen). There are three of them in this  
> example:
> 1. The ASAS observations, providing time, position, and magnitude
> 2. The Roalnd observations, again time, position, and magnitude
> 3. The orbital elements for the parabolic orbit fit.

...which is to say that a VO time series would be a construct with  
the independent spatial and temporal variables wrapped around the  
dependent variables, e.g., photometry and spectroscopy and the  
characterization of moving bodies, but also things like  
asteroseismological data, or parameters embedded in time series  
embedded in columns of detection or source catalogs, or telemetry  
such as neutrino event coincidences and gravitational wavefronts, or  
presumably all time series of any other sort (movies of CMEs?)

This sounds like an interesting philosophical discussion, but causes  
one to pause at the thought of making timely progress on various  
fronts, in particular those related to VOEvent.  Perhaps somebody can  
comment on the viability of multiple representations conforming to a  
common underlying DM?  Maybe the STC data model could serve as the  
underpinnings of a simplified VOEvent representation?  Or is DM  
really taken to mean "schema"?

As far as multiple instances or other changes to <WhereWhen>, I think  
we can presume that a VOEvent v1.2 will be needed to adopt time  
series as well as other interesting features raised at the Hotwired  
workshop (although time series are more likely to appear under the  
<What> element methinks).  This is likely, however, to also leverage  
changes to STC as well as other standards such as UCDs.

For instance, a time series will typically represent prior  
observations, but <WhereWhen> may typically be taken to represent  
targeting instructions for any general follow-up observer.  That is,  
targeting coordinates should not be colored by the  
ObservatoryLocation of past data.  Including this is basically  
requiring that all client code remove the same obsolete observatory  
signature.  Why not have the author/publisher do this once, not  
coincidentally simplifying the packet significantly?

I am eager to seek a consensus that STC be used as the DM (and to  
represent) orbital elements.  However, is the proposal on the table  
really that every point in a light curve be represented like:

>         <AstroCoords coord_system_id="UTC-ICRS-TOPO-VMAG">
>           <ScalarCoordinate unit="mag" frame_id="Vmag">
>             <Value>12.0</Value>
>           </ScalarCoordinate>
>           <Time>
>             <TimeInstant><ISOTime>2006-01-04T00:53:46</ISOTime></ 
> TimeInstant>
>           </Time>
>           <Position2D unit="deg">
>             <Value2><C1>322.88750</C1><C2>-67.51833</C2></Value2>
>           </Position2D>
>         </AstroCoords>

And how does this mesh with SSA and other protocols?  Will the two  
obvious vectors (or columns) of ascii or binary numbers, however  
represented, be disallowed?

I'm delighted that STC proves so flexible.  Presumably a conforming  
library could be used to move back and forth from vectors to this  
list of extremely well tagged data points.  The fragment above is 437  
bytes - to represent two 4 byte floating point numbers, in effect.   
To be fair, the position may not appear in typical usage, but on the  
other hand what is the overhead of turning this into canonical XML  
for digital signing purposes?  So maybe it won't be the 50:1 data  
inflation seen here - but then, maybe it will be more.

Once a time series rises above a few hundred points, it is hard to  
see how this will be  acceptable for many purposes.  It starts to  
border on the notion of so representing every pixel of an image -  
after all, a CCD is nothing but a time series with microsecond  
spacing along the shift register.

Or look at it another way - an image with a WCS is a "space series".   
Where is the equivalent parametric fit for time - a TCS, if you will  
- that can be attached to a time series?  This should be a simpler  
problem (for most real world problems) if only because a time series  
is a 1-D vector, not a 2-D (or higher) array.  Yeah, you can come up  
with pathological cases - by all means Arnold is welcome to these -  
but a nice barycentric light curve, evenly or unevenly gridded, is  
something a sophomore can do:

	http://www.konkoly.hu/IBVS/1701.html#1701

I guess Doug's comments will apply to time series as well as spectra:

>> Hence, SSA provides both active mediation (on the server side) to a
>> standard data model, as well as pass-through of unmodified native  
>> data.

Our interest in VOEvent is precisely to encourage providers (author/ 
publishers) to converge on standard representations of a standard  
DM.  I fear that a provider needing to distribute even  
straightforward photometric light curves of modest size will balk at  
surrounding their vectors with such a scaffolding of precision XML,  
where they might otherwise be convinced to adopt a VOTable or FITS  
solution, for instance.  There isn't much point in picking a standard  
that is guaranteed to be routed around using native data.

Alasdair, where is that napkin?

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20070626/6c94b826/attachment-0001.html>