On the "when" and "where"

[Rob Seaman]

Judging from the discussion so far, this should be an interesting 
workshop.

Alasdair suggests we need:

> Ease of implementation and keeping the learning curve as shallow as 
> possible...

If you rummage around you'll find that my few previous contributions to 
the mailing lists focused precisely on this issue.  (In fact, I recall 
making the same point over beers at the June 2000 meeting at Caltech 
when presented with some flights of XML fancy.)  We need to keep the 
buy-in low enough that our intended users will actually use our 
systems.

That said, our systems have to also actually do what we intend them to. 
  The general case of specifying (useful) astronomical coordinates and 
times is intrinsically quite complicated.  We will either support that 
general case - or we will limit the types of events that can be issued. 
  We should be open to arguments on either side, but whatever the choice 
is, it should reached through an explicit analysis on our part.  
Perhaps solar events aren't to be supported, but moving solar system 
objects are, etc.

>> For example, a VOEvent describing a solar flare would not benefit 
>> from supplying an RA and Dec that won't apply at any point after the 
>> event is issued due to the rotating Sun and orbiting Earth.
>
> Yes, so you (obviously) don't supply an RA or Dec. This is a case 
> where defining the original frame of an observation is necessary. In 
> most cases (non-solar) you'll probably just want to publish and RA, 
> Dec and time stamp, at least initially.

By original frame I'm guessing we're talking about the 
InstrumentConfiguration - the "how" - of the event?  I'm not sure how 
useful this will prove in practice, external to some specific 
institution.  The nature of the VO is such that the signature of 
specific instruments should be removed as much as possible.  In the 
case of events, we are attempting to do so perhaps even more so than in 
archival holdings.  Our intent is to capture the essence of either a 
detection or a rapid object classification and to convey this essence 
to the community as a whole.  This is at the far end of the processing 
spectrum from the raw data.  The fact that an event might have resulted 
from running sextractor on a pair of time shifted frames from a wide 
field imager is immaterial.  The event is an explicit scientific claim 
that some transient behavior was noted in some direction at some 
(perhaps barycentric) time with some estimated photometric, astrometric 
and clock errors.  Abstracting the coordinates and time under STC is 
potentially appropriate.  Leaving same to be manually scavenged from 
instrument specific metadata is not.

> Why add the burden of having to implement a parser for a full blown 
> STC spec, a lot of which is irrelevant to your telescope. My ground 
> based optical telescope doesn't need to know how work out the 
> co-ordinate frame translations to observe a solar flare, so why should 
> I be forced to implement this?

Why would VOEvent, per se, have to implement this parser at either end? 
  One could make the case that VOEvent doesn't need to know anything 
about coordinates or time, at all - beyond the utility of a transport 
timestamp perhaps.  The users of VOEvent will need to understand enough 
about this issue for the purposes of their class of events.  Perhaps a 
simple RA, Dec, Frame (with implicit epoch), and UTC (with real civil 
time issues brewing) would be enough for a particular project.  Another 
project might require highly precise and esoteric coordinates.  It 
seems to me that an abstraction like STC is precisely how you support 
such a range of users.

The VO will have trouble convincing others to adopt its standards if it 
isn't even willing to adopt them itself :-)

Rob Seaman
NOAO