[nvo-techwg] Time series data

[Arnold Rots]

I only asserted that STC *can* provide the functionality.
And, of course, it does that with minimal change to the VOEvent
standard and schema - that's leveraging capabilities that are already
built in.
Anyway, 437 bytes is peanuts compared to the 18 kB of your message ;-)

Cheers,

  - Arnold

Rob Seaman wrote:
> 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
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------