[Fwd: VOTimeSeries]

[Rob Seaman]

On Jul 2, 2007, at 8:38 PM, Doug Tody wrote:

> 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.

A VOEvent <Reference> is a URI with a name and a type.

I was more interested in pinning down the rather interesting content  
and behavior that you describe.  Design is a tug-of-war between  
freedom and constraint.  Complete freedom to point at anything just  
ensures that applications in the field will have to reject many  
references as being unintelligible.

VOEvent packets don't command telescopes, but their content does  
influence follow-up telescope behavior (potentially extremely  
expensive behavior).  I won't belabor the risks of acting on packets  
that trigger arbitrary remote services - the word "virus" springs to  
mind.

> 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.

Yeah, I've gently asserted this idea at various points in the past  
(in fact, somebody else mentioned something similar at a telecon  
yesterday).  It has not been welcomed so far.  But relying purely on  
references stored on remote servers opens unattractive possibilities  
like later triggering a massive assault on those servers - especially  
in the era of 10^5 LSST events nightly batched and (it now appears)  
eagerly replicated.

> 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.

VOEvent has been very successful at engaging elements of the larger  
community - not just the HTN robodroids, but also various groups  
involved in their own idiosyncratic event publication projects.  We  
need to represent time series data because groups such as AAVSO,  
CBAT, MPC and ATEL want to publish such.  These may be very  
interesting time series because of groups like SNEWS and LIGO.  In  
the past two years I would guess that we've been in contact with 40  
or 50 diverse survey and event and transient response projects.

> If all you need is some vague notion of the time variability of a  
> source there might be simpler solutions.

For several use cases you are undoubtedly correct.  For instance,  
orbital elements can be viewed as a way of parameterizing past and  
future time series behavior.  But if J. Random Astronomer wants to  
publish a list of magnitudes, errors and times then so do we.

> There are important questions which have not been discussed here,  
> such as where this time series data comes from, how it is used,

For VOEvent the answers are as broad or broader than any other VO  
science cases.

> how we avoid problems of source confusion if the data is merely  
> retrieved from some archive, and so forth.

This seems a little less pertinent.  VOEvent is more tied to the  
pipeline side of the business than to "static" archives.  A bigger  
question is shelf life.

Rob