[Fwd: VOTimeSeries]

[Doug Tody]

On Mon, 2 Jul 2007, Rob Seaman wrote:

> issue is that date and time must form an atomic whole.  Perhaps the best way 
> to eliminate this issue is to avoid "time" fields entirely in favor of "date" 
> analogs as with FITS DATE-OBS.

For most time values we use absolute time values formatted as ISO 8601
(like DATE-OBS), however for precision time values within an observation,
it is preferable to use a zero point - offset scheme, e.g., MJD for the
zero point, and offset in seconds or days for the individual time values.
This is especially important if there are many time values, as in a
large time series.  It is up to the data provider to specify the units
used and ensure that the metadata is correct.

>>>> Since the data model is defined independently of the serialization, there 
>>>> is no need to pick a single serialization.
>
> Which I understand to imply that VOEvent - an XML publication standard - 
> might settle on a distinct time series representation from other VO 
> applications relying on CSV, FITS, native VOTables, or "graphical rendition" 
> (e.g., IRAF GKI metacode, I suppose).

You could do that and still use the data model.  However it would
require custom software to read and write the time series object; to use
a standard tool that doesn't support VOEvent would require some custom
software to extract the data into a standard format.  But this would be
better than inventing a new data model that does the same thing as what
we already have.

The alternative would be to treat the time series as an object, and
somehow attach or embed it in the VOEvent, e.g., as a VOTable.  This would
allow standard software to be used once the object is extracted from
the VOEvent "container".  Either approach could work.

Note, there is also a direct XML serialization of the data model which
is already defined.  If you have to use native XML you might want to look
at that.  Most applications though prefer to work with VOTable or FITS
so that generic tools can be used.

	- Doug