On the "when" and "where"

[Rob Seaman]

Roy Williams writes:

> I quite agree with you that simplicity is not enough, and that the 
> VOEvent schema should include a comprehensive space-time specification 
> such as STC. But at the same time, I do not want to lose simplicity.
>
> Questions
>
> -- If I wish to report an event that happened at given RA, Dec with a 
> one-degree error disk, how simple can the STC specification be?
>
> -- If I wish to report an event that happened at some time within a 
> 6-hour exposure, how simple can the STC specification be?

Take a look at example B.4 from 
http://www.ivoa.net/Documents/PR/STC/STC-20050315.html and omit the 
PixelSpace reference for an idea of the complexity.  This is an 
example, of course, of an event that corresponds to a single 
observation.  Perhaps Arnold has a better example.

I'm not quite sure what to make of the statement that "simplicity is 
not enough" tied to "I do not want to lose simplicity".  The general 
case of reporting an event can be quite "interesting".  Either that 
complexity needs to be supported by the standard - or the standard must 
be limited to only a simplified set of event types.  I think one of 
Arnold's main points was that a VOEvent could inherit (in both the 
colloquial and technical sense) support for the full range of 
coordinate support from STC.

> -- Can I take a time as specified by LIGO and put it into STC? Or a 
> time as specificed by GCN? Is the translation straightforward?

I think the point would be to support reporting in any useful timescale 
that might be adopted by VO member organizations. STC currently claims 
support for:  TT, TDT, ET, TAI, IAT, UTC, TDB, TEB, TCG, TCB, LST and 
LOCAL timescales.  Some of these are synonyms or are deprecated, but 
presumably there is also some mechanism for adding to the list.  At any 
rate, the need for translating coordinates within VOEvent is not 
obvious beyond the requirement that the coordinates be understandable 
to anybody likely to benefit from subscribing to a particular type of 
event.

Please see the letter from McMarthy, et.al. in the March 2005 AAS 
Newsletter for sufficient reason to be concerned about blindly using 
MJD or any other way of expressing UTC.  VOEvents must support multiple 
choices for the timescale.

I see that Arnold has also replied to confirm some of my information:

> Two points:
> - STC does tie time to a spatial frame.  ObsDataLocation requires an
> observatory location which <TOPOCENTER> refers to; other explicit
> spatial locations are in the package as well.
> - STC does also include specification of areas in all coordinates -
> regions and intervals.

I haven't fully digested STC, but there appears to be a distinction 
between a Time Frame and a Coordinate:

	"The Time Frame contains two or three objects: a reference position,
	a time scale, and, optionally, a time reference direction."

Whereas:

	"A Coordinate is an aggregate of up to 6 objects: CoordName, 
CoordValue,
	CoordError, CoordResolution, CoordSize, and CoordPixSize."

In this, VOEvent v0.3 has the advantage of expressing a "TimeError", 
while STC appears not to.  (Or perhaps a Time Frame IS a Coordinate?)  
Certainly the resolution of the clock might be at least as important as 
the resolution of the setting circles on a virtual telescope.

Rob Seaman
NOAO