moving time and space

[Rob Seaman]

Alasdair Allan writes:

> If developers need to construct (or parse) a document as complicated 
> as the STC examples I've seen simply to pass the RA, Dec, epoch and 
> equinox of an observation then I think the VO has a real problem.

Focusing only on scalar representations of RA, Dec, Equinox and Epoch 
would severely limit the range of event types that can be supported.  
Consider a typical FITS header.  Rarely are the equatorial coordinates 
in the RA, DEC and EQUINOX keywords of any benefit to processing.  A 
complete WCS is necessary to perform typical astrometric chores.  
Similarly, a scalar DATE-OBS timestamp is of little utility without 
ancillary explanation.  Does the keyword represent the start of the 
exposure, or the end?  Is the instrument's system of time really UTC?  
Is the quoted time topocentric or barycentric?  If topocentric, where 
is the observatory located - or rather, where was the observatory 
located at the time of the observation?  The positional and temporal 
coordinates are inextricably related.

The coordinate recording requirements for event reporting are not a 
one-to-one match with the requirements for instrument data streams - 
but they have significant overlap.  It may well be that there is a 
significant class of point sources events that can be expressed 
succinctly by the equatorial coordinates (including equinox) and epoch 
with prudently chosen defaults for the underlying coordinate system 
(FK5 and UTC, for instance).  Combine this with default units (hours 
for RA, degrees for Dec, years or Julian days for epoch), default 
representations (sexigesimal and/or decimal) and perhaps implicit 
numerical precision and you might have a relatively complete 
specification that can be squeezed into 10 lines of XML (always bearing 
in mind that those might be very long lines :-)

What you will have, though, is something that cannot represent solar or 
planetary coordinates, that may not be able to represent a moving 
target in general, that may not lend itself to expressing coherent time 
series, that provides no support for extended sources or detections, 
that doesn't in fact distinguish between source events (Olympus Mons 
surprisingly decides to erupt) and detection events (a GRB located in 
the general direction of Ophiuchus).

> Fine, allow an STC structure as one *possible* way to represent the 
> co-ordinate/time structure,

A consensus has been forged!

> although I'm still totally unconvinced that the link between 
> co-ordinate and time structures is necessary or even desirable.

I guess I don't understand this.  For many purposes, an RA *is* a time. 
  And a time is often an angle.   Our observatories are in motion - even 
the ground based ones.  Many of our targets are in (perceptable) 
motion.  A measurement of the position of an event depends on when the 
measurement was taken.  Heck, RA and Dec are meaningless without an 
Equinox.

On the other hand, many astronomical events are of interest precisely 
because they occur within a series of other events.  Placing an event 
at the appropriate time in the series often depends on compensating for 
the locations of the observatory or the target.  For instance, the 
characterization of the light curve of a SN requires correcting each 
observation for the differential light travel time across the Earth's 
orbit.

Perhaps you are speaking solely of linking the data structures?  I 
would think the Zen of XML would suggest that two quantities that are 
related in the problem domain should share a similar relatedness in 
their representation.

Shouldn't our software objects resemble the objects we study?

Rob Seaman
NOAO