seaman at noao.edu
Tue Jul 3 09:53:14 PDT 2007
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
> 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)
> 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
> 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.
More information about the dm