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 Received on 2007-06-26Z22:09:32