Wide or Narrow Schema for VOEvent?

[Rob Seaman]

Roy asks a good question:

> Here is a question regarding the reporting of positional information 
> for astronomical events.
> Should the reporting standard be (a) Very Narrow, [or] (b) Very Wide,

...a good question with two premises that I reject.

First (and I suspect Arnold would agree), the positional information is 
integrally tied to the temporal and spectral information and to 
derivatives of same.  This is the message of STC, but is also the 
message of VOEvent, as well, precisely because a single event exists to 
tie together the what, where and when (as well as the who and how).  We 
don't have the freedom to make the positional information narrow or 
wide independently from the the temporal or spectral/bandpass 
information.

Second, I'm a bit bemused what VO has been doing over the last half 
decade.  It seems like a lot of attention has been focused on the 
"Virtual", perhaps at the expense of the "Observatory".  It is most 
certainly true that creators of astronomical events might want to:  
"use galactic coordinates, or Jovicentric coordinates, or coordinates 
in equinox B1870.0, or Martian longitude/latitude" and many other 
options besides.  If VO were attempting to create some other virtual 
domain, for instance, the Virtual Genome or the Virtual Atmosphere or 
the Virtual Earth, would a premium exist on limiting a particular event 
reporting standard to a nonphysical subset of the actual events that 
occur?

I believe:

1) The VOEvent standard is required to support a "wide" range of 
coordinate types.  STC is a good place to begin to sort this out.

*and*

2) A particular VOEvent is required to be straightforward to construct 
and interpret (assuming we actually want the standard to be implemented 
and used in operational systems).

The distinction between these two perceived extremes is only that any 
standard must be just flexible enough to support the actual needs of 
its users.  To achieve this, I assert that a VOEvent should be a 
delivery vehicle for some payload similar enough to STC for the 
distinction not to matter.  The delivery vehicle will attend to 
identification, authorization, classification and other administrative 
needs.  The payload will deliver the science.  It may *also* be true 
that the vehicle might directly convey a simplified (to the point of 
non-utility in some cases) representation of the payload (such as RA, 
Dec, Equinox, Epoch with coordinate frame and timescale defaults) - but 
the requirement for this has not been made clear (to me, anyway).

A particular originating project will then craft a payload just 
complicated enough to convey their science.  A particular consumer will 
either be able to handle that payload - or wouldn't be able to handle 
events being distributed by that project in any other format anyway.  
The administrative overhead of the standard should be minimal enough 
that events can be easily routed throughout the community - and without 
repeatedly parsing the payload.  The ease of delivery is the real value 
of VOEvent.  Improving the payload (STC and/or otherwise) is a separate 
issue.

In any event, I imagine Roy's intent with casting the choice between 
the extremes of "very narrow" and "very wide" was to suggest that we 
seek a compromise one-size-fits-all, sans-a-belt solution (with a 
"skosh more room" :-)

Rob Seaman
NOAO