I have just submitted the following response to the SpaceTime schema
proposals by Arnold Rots. I've sent it to [log in to unmask] so hopefully
it will appear OK.


David





Arnold,

Some initial comments on the "Space-Time Coordinate Specification for VO
Metadata" (based on the HTML explanation document):

- Inclusion of Doppler velocities and redshifts: Since these are
basically re-scaled forms of wavelength or frequency, should they not be
included with the wavelength/frequency/energy schema instead of the
space-time schema? Including them in the space-time schema may produce
confusion between these "formal" velocities and "real" velocities.

- Regarding the DopplerReference item, is "LSR" the kinematical or
dynamical LSR (presumably the kinematical, but should support be included
for the dynamical LSR?) See:

http://www.starlink.rl.ac.uk/star/docs/sun67.htx/node227.html

- Planetary coordinate systems are included, but there doesn't seem to be
any mention of solar or STP coordinate systems.

- The planetary coordinate systems seem to be restricted to spherical
longitude/latitude. Is it possible to describe ellipsoidal surfaces?
(e.g. geodetic longitude/latitude instead of geocentric).

- Spherical coordinates seem to be restricted to longitude/latitude
systems. Is it possible to use co-latitude in place of latitude? Some
solar coordinate systems require this.

- Positions within a single physical Domain (such as "the sky", or "the
solar system", or "a spectrum", etc) can in general be described using
many different coordinate systems. It is common for the Mapping between
these coordinate systems to vary with time.  To enable conversion between
such coordinate systems to be possible, it is therefore necessary to
specify a moment in time which defines each coordinate system. I couldn't
find such a time in the CoordsSystem element (although it's quite likely
that I missed it). TimeRefPos seems to be for a different purpose.

- It would be interesting to see a UML diagram (or equivalent) showing a
class hierarchy which could be used to represent the elements of the
schema. Presumably you would need two basic classes to represent the
CoordSystem element, a Domain (representing a physical domain, "SKY",
"TIME", "SOLAR-SYSTEM", "SPECTRUM", "SUN", "JUPITER", etc), and a
CoordinateSytem class which indicates the type of coordinate system
(Cartesian, polar, lon/lat, long/co-lat, etc). Each Domain would
encapsulate a set of named CoordinateSystems each corresponding to a
different coordinate system which can be used to describe positions
within the Domain. For instance, the SkyDomain class (a sub-class of
Domain) would have several LonLatCoordSystems corresponding to FK4, FK5,
ICRF, FK4-NO-E, GAPPT, etc.



Apologies if any of these comments reveal the fact that I am new to this
discussion, and havn't fully grasped the background!

The schema seems to have been specifically tailored to the current needs
of the bulk of astronomical data. How easy would it be to extend the
schema in future to cover other coordinate systems not currently in
demand? For instance, could a cylindrical coordinate system describing
the solar system (or a galaxy) be easily incorporated?


David