Space-Time Coordinates Metadata for the Virtual Observatory

Space-Time Coordinate (STC) Metadata Specification for VO

Version 1.30

Arnold Rots, SAO/CXC, 2012-05-30

This directory contains version 1.3 of the STC schema which is the official IVOA Recommendation version.

STC has been developed as part of the National Virtual Observatory (NVO) project, in the wider context of the International Virtual Observatory Alliance (IVOA).

Scope

The objective is to provide a metadata description of the volume in space-time parameter space that is occupied by, available in, or requested by: a data set of any kind, a resource, or a query. The "space" part of this parameter space includes spatial coordinates of any kind: spherical coordinates, 2-D (e.g., detector coordinates) and 3-D Cartesian coordinates, one-dimensional coordinates. Also included are the spatial time derivatives: velocities (space velocities and proper motions), spectral coordinates, and redshifts/Doppler velocities. These last ones are treated separately since they are derived quantities based on a formalism, rather than physical velocities (i.e., the value depends on the formalism, which is not applicable to true velocities).

What this means for an image, for instance, is that the metadata describes very precisely and unambiguously what piece of space is represented or occupied by the image. However, a separate metadata object is still needed to specify how that spatial volume is projected onto a pixel array. After careful consideration it was decided that separating the information into two metadata objects (one that specifies the space-time coordinates, including the pixel space, associated with the data and another that specifies the projection onto that pixel array) is the correct way to model the metadata in this area.

We strongly emphasize that space and time metadata need to be encapsulated in a single metadata object. Although it is true that for the majority of the data that are moved around this is totally unimportant (very few people besides historians will care when a particular photograph of M81 was taken), there are a number of cases where it is crucially important (e.g., high time resolution pulsar observations). We feel that the link needs to be enforced from the outset; it will be very difficult to retrofit it later if it were initially neglected. In other words: we need to do this right from the beginning.

Documentation

Standards Document

The final version of the Recommendation in HTML or PDF format.

A chapter on STC may also be found in the NVO Book which is accessible on-line.

Model

The STC Model and its hierarchy are presented in a PDF file, serving as an explanatory supplement and glossary to the STC Recommendation. It shows all components that are, or may be, needed to specify STC metadata in their location in the hierarchy, with brief descriptions where needed. I would suggest that one explore the model through the PDF Bookmarks.

A set of UML diagrams of the coordinate system design is provided here in PDF format.

XML Implementation

The full STC schema is documented here. Rob Seaman asked for this, but beware - it's very large.

A full list of units strings that are allowed in STC and a list of global elements.

Changes

The most significant changes from version 1.21:

A new referencing mechanism, Xlink, that is robust and flexible; in case of ambiguities, the precedence is:
1. Content of the element
2. Content of element referred to by IDREF attribute
3. Content referenced by Xlink attributes
4. UNKNOWN
Any element that is either missing or which content cannot be determined is assumed to be UNKNOWN, in which case it is up to the client to either reject the document or choose a suitable default.
Replacing Lists of doubles (i.e., arrays, particularly in multi-dimensional - spatial - coordinate axes) by explicit enumeration of the individual components.
Allowing units to be specified at all levels of coordinates (i.e., also at the leaves).
Simplified version of error circles in 2-D and 3-D
Name optional in Coordinate elements, Timescale optional in astronTimeType
Rename Region Shape "Constraint" to "Halfspace".
Add "Difference" to Region operations (redundant but practical).
Optional epoch attribute; precedence:
1. Epoch provided in coordinate leaf element
2. Epoch provided in higher coordinate node
3. Time of observation
4. Equinox of, or implied by, coordinate system
5. UNKNOWN
Note that under most circumstances, where an observing time is provided, epoch is not needed.
Allow position to be specified by orbital elements.
Allow definition of a position path (curve).
Removed all anonymous types.
Added application-specific types (in particular for footprint service).
Consolidated everything in one schema.
Added basic support for generic coordinates.
Added an optional UCD attribute to the basic STC attribute group.
Revised inheritance structure: Pixel and Astro versions of CoordSystem, Coords, and CoordArea now derive from the generic ones by extension, and thus include the generic versions as well.
Coordinate transformations are now fully supported through the CoordRefFrame mechanism.
Full support for orbital elements.
An attribute handedness (right or left) was added to a Frame's Flavor.
Support was added for identifying ID and IDREF attributes through ID_type and IDREF_type attributes; this helps applications like registry to identify those kinds of attributes without having to refer to the schema.
GPS is recognized as a legitimate time scale.

STC-X: XML Schema

The XML schema implementation consists of one XML Schema file:

Current version of the stc.xsd schema
In addition, the Xlink schema is needed: xlink.xsd

Code

The XMLSpy-generated code is available in tar files for:

XML Examples

Below are 19 examples of XML files built with the schema (note that the style sheet is not yet up to date, although there is a new style sheet for coverage descriptions):

M81event: the WhereWhen part of a VOEvent, using references for ObservatoryLocation and AstroCoordSystem, and a polygon for the error box.
M81image: the full STC metadata description of an image of M81, without the use of references.
M81KPNOref: the simplified STC metadata description of an image of M81, using references.
G1Arecibo: a full STC metadata description of an Arecibo HI survey, in Galactic and equatorial coordinates and using a reference for the ObservatoryLocation.
S1Arecibo: a query in STC metadata for a subset of the Arecibo survey.
ChandraSTCResource: a resource profile description of the Chandra archive.
Query: a query expressed completely in terms of an STC metadata description.
GalCatalog: the STC metadata describing a catalog of galaxies.
JCMexample: an example cooked up by Jonathan McDowell, with a rather unusual reference position.
mytest_circle3: an example of the use of the application-specific global type STCRegion that allows documents to contain just a region description.
Orbit: an example of the ephemeris of an elliptical orbit from an MPEC, presenting orbital elements
ParOrbit: an example of the ephemeris of a parabolic orbit from an IAU Circular, presenting orbital elements.
Orbit (long): an example of the ephemeris of an elliptical orbit, presenting three different representations.
stcTab.xsd: an example of how one can construct simple application schemata that are based on stc.xsd; this example allows one to construct xml documents consisting of tabular data with adequate STC metadata attached.
List of positions: an example of how one can construct a simple list of positions on the basis of stcTab.xsd.
Time series: an example of how one can construct a time series on the basis of stcTab.xsd.
Event list: a format is defined for a photon event list on the basis of stcTab.xsd.
Spatial coverage: an example of some simple spatial coverages; this document is associated with a toy style sheet that converts its STC-X XML into STC-S strings. The style sheet is not meant to be full-proof, but will handle a number of spatial (only) coverages.
STC-S example: a more extensive example of STC-S translation.

STC Region Encoding

The STC standard provides for the general exchange of Region descriptions: a simple XML document that contains either a single Region (using an element with xsi:type="STCRegion") or a list of Regions (using an element with xsi:type="STCRegionList") This is the exchange format used in the JHU footprint service. Considering that there is a standard XML serialization of Regions, it makes sense to use this format when exchanging Region descriptions in XML. An example of such a description may be found here.

As to the question what is the best way to incorporate Region descriptions in a larger document, I will give examples of three possible approaches. For convenience, they are all based on the little utility schema mentioned above, which allows putting all kinds of coordinate information in a simple table. This simple schema defines an STC metadata element and a plain table where components of the STC metadata can refer to specific columns in the table through ID/IDREF pairs; this ensures that the place of each datum in the metadata model is fully specified. The three examples implement the description of a 0.4x0.2 degree area in different locations on the sky, with different position angles. The table contains fiducial URLs to the supposed image data that should be ignored.

First, the brute-force way: simply embed the Region elements (Polygons) in the table itself: My5EmbeddedRegions.xml. It shows that it is perfectly feasible to embed this information in any document.
Next, referencing Regions that are recorded elsewhere, which makes the table much more compact. The table is My5XlinkRegions.xml, while the actual Region descriptions may be found by following the XPath (2.0) pointers in the Xlink hrefs to the XML document that contains all the descriptions: My5Polygons.xml.
Third, is there a way to compress the total volume of XML, by parameterizing the five congruent Regions? There is, in the third example: My5TransformRegions.xml. Here the Region shape is specified once in the Table metadata and properly defined through a transformation element that has its parameters specified in each table row.

STC-S: String Implementation

STC-S is a "command line" implementation of STC, meant to provide a concise and transparent encoding of the STC metadata suitable for embedding in, for instance, an ADQL query or a Dublin Core registry description.
STC-S at the IVOA site (previous version).

Current version of the Working Draft: