[Fwd: VOTimeSeries]

[Doug Tody]

On Mon, 2 Jul 2007, Rob Seaman wrote:

> What precisely would a VOEvent packet be pointing to with an embedded
> SSA reference?  Should we decide, rather, to embed native SSA time
> series serialized XML within a published VOEvent packet, what would

Just to expand upon this point: if you were to embed a reference to an
external "SSA" (timeSeries) dataset in a VOEvent, the reference would
be a URL, just as you saw in the second URL in Enrique's sample service.
Accessing the URL might invoke a service, it might return a cached file,
or anything else that URLs can do.

What might be nice would be if the VOEvent core XML packet could be
packaged with other data so that the URL could instead point to data
included within the event package.  Then you could decide whether or not
to package the data up within the event, providing the same URL-based
interface for both included or external data, keeping the core event
structure clean and simple, providing more flexibility in terms of
what is included, and so forth.  Then if you wanted to include not
only a VOTable but a small JPEG or whatever, it would be possible to
do so and still have a lightweight mechanism, without complicating the
schema of the core event structure.  This would provide a more layered,
flexible approach, rather than trying to define an ever more complicated
core schema.

I still think though, that a lot of this turns on what is really driving
this; what your primary use cases are for time series data in events.
It is not clear if you need real time series data, or if something simpler
might do.  If all you need is some vague notion of the time variability of
a source there might be simpler solutions.  There are important questions
which have not been discussed here, such as where this time series data
comes from, how it is used, how we avoid problems of source confusion
if the data is merely retrieved from some archive, and so forth.

	- Doug