I nternational
V irtual
O bservatory
A lliance
Registries provide a mechanism with which VO applications can discover and select resources—first and foremost data and services—that are relevant for a particular scientific problem. The IVOA RegTAP standard prescribes a set of tables that allows querying against a broad set of metadata within the VO registry; it does not, however, talk about constraining resource coverage in the spatial, temporal, spectral, and redshift axes. This specification fills this gap, thus complementing RegTAP.
This is an IVOA Working Draft for review by IVOA members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress".
A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
This document has been developed in part with support from the German Astronomical Virtual Observatory (BMBF Bewilligungsnummer 05A08VHA).
The words "MUST ", "SHOULD", "MAY", "RECOMMENDED", and "OPTIONAL" (in upper or lower case) used in this document are to be interpreted as described in the IETF standard RFC 2119 [RFC 2119].
TO BE WRITTEN
This specification directly relates to other VO standards in the following ways:
This standard also relates to other IVOA standards:
VOResource records can contain coverage information expressed according to the IOVA data model for Space-Time Coordinates [std:STC]. The complete data model is far too large and complex for a relational representation. However, a rough indication of the regions in time, space, and the electromagnetic spectrum covered by a resource is sufficient for many registry purposes, in particular focusing queries to a smaller subset of resources by weeding out ones which do not intersect with the region of interest.
This section defines a set of tables giving, for each resource and STC axis, zero or more intervals covered by the data.
To make queries feasible, the STC coverage tables have fixed STC metadata, viz,
While it is expected to rarely matter at the level of precision the registry aims for, the reference position SHOULD be the solar system barycenter, except for time, which SHOULD be given for the geocenter.
Resource registry authors SHOULD provide their metadata in these standard forms, but registry ingestors SHOULD make a best effort to transform STC metadata given in other forms.
The utypes used here are taken from the STC data model, formed according to the rules in [STCVOT].
Services providing the following tables should declare support for
the data model ivo://ivoa.net/std/RegTAP/stc
in
their TAP capabilities:
Table Utype | Description |
---|---|
rr.stc_redshift stc:AstroCoordArea.SpectralInterval | The redshift coverage of resources, given as one or more intervals; the total coverage is (a subset of) the union of all intervals given for a resource. Redshifts here are understood as delta lambda/lamda. |
rr.stc_spatial stc:AstroCoordArea.Region | The spatial coverage of resources; the total coverage is (a subset of) the union of all regions given for a resource. All coordinates are in ICRS. There is no notion of how tight the given regions are. |
rr.stc_spectral stc:AstroCoordArea.SpectralInterval | The spectral coverage of resources, given as one or more intervals; the total coverage is (a subset of) the union of all intervals given for a resource. All spectral values are understood as given as wavelength in meters; they are supposed to express wavelength at the barycenter of the solar system (which means instrument values should be close enough to work). |
rr.stc_temporal stc:AstroCoordArea.TimeInterval | The temporal coverage of resources, given as one or more intervals; the total coverage is (a subset of) the union of all intervals given for a resource. All times are understood as MJD in the TT time scale. |
In the following table descriptions, names and utypes of tables and
columns are normative and MUST be used as given, and all-lowercase.
Descriptions are not normative. Registry operators MAY provide
additional columns in their tables, but they MUST provide all columns
given in this specification. All values of the ivoid
column must be lowercased on ingestion.
The stc_spatial
table links IVORNs with zero or more
bounding boxes, understood as intervals in Right Ascension and and
Declination (note that this means the bounding lines in latitude are
not great circles). This is an admittedly rough model, but since in
principle, a service can define arbitrarily many such patches, any
desired accuracy can be obtained. However, since the these items are
given for discovery purposes, to weed out irrelevant
services in all-VO query, and similar tasks, a fairly sketchy
specification of coverage should be sufficient.
While ADQL would support defining and querying more sophisticated regions, using these for coverage is not straightforward; one reason is that the natural candidate for a coverage column type, POLYGON, cannot easily represent the entire sky or similarly large coverages, which means ingestors would have to employ fairly advanced spherical geometry to split such large regions up. Also, in data discovery the actual shape of the covered regions is probably not usually important.
Currently, fully general STC specifications are allowed in registry records. It is not expected that many registries will sensibly support a significant part of the constructs possible and the transformations involved. For interoperability, resource record authors should give spherical position intervals in ICRS exclusively. A short IVOA note will discuss the recommended format of coverage declaration.
Name Utype | Type | Description |
---|---|---|
ivoid vr:Resource.identifier | adql:VARCHAR(*) | The parent resource |
ra_min stc:AstroCoordArea.Position2VecInterval.LoLimit2Vec.C1 | adql:REAL | A left edge of a bounding box on the sky the resource covers. |
ra_max stc:AstroCoordArea.Position2VecInterval.HiLimit2Vec.C1 | adql:REAL | An right edge of a bounding box on the sky the resource covers. |
de_min stc:AstroCoordArea.Position2VecInterval.LoLimit2Vec.C2 | adql:REAL | A lower edge of a bounding box on the sky the resource covers. |
de_max stc:AstroCoordArea.Position2VecInterval.HiLimit2Vec.C2 | adql:REAL | An upper edge of a bounding box on the sky the resource covers. |
The ivoid
column should be an explicit foreign key into
resource
.
It is recommended to maintain an index on
the area_covered
column.
Temporal coverage is given by associating one or more time intervals to an IVORN. Both start and end are mandatory, i.e., there are no half-open intervals. All times are given in days in the MJD epoch. While it should rarely matter, we note that times are supposed to be in TT in the geocenter.
Name Utype | Type | Description |
---|---|---|
ivoid vr:Resource.identifier | adql:VARCHAR(*) | The parent resource |
time_start stc:AstroCoordArea.TimeInterval.StartTime | adql:REAL | Lower limit of a time interval covered by the resource. |
time_end stc:AstroCoordArea.TimeInterval.EndTime | adql:REAL | Upper limit of a time interval covered by the resource. |
The ivoid
column should be an explicit foreign key into
resource
.
It is recommended to maintain indexes on
both the time_start
and time_end
columns.
The stc_spectral
table is constructed analoguous to
stc_temporal
, i.e., each resource has one or more
associated intervals, for which both upper and lower limit is mandatory.
The limits are given as wavelengths in meters, for the reference
position in the barycenter of the solar system.
Name Utype | Type | Description |
---|---|---|
ivoid vr:Resource.identifier | adql:VARCHAR(*) | The parent resource |
spectral_start stc:AstroCoordArea.SpectralInterval.LoLimit | adql:REAL | Lower limit of a spectral interval covered by the resource. |
spectral_end stc:AstroCoordArea.SpectralInterval.HiLimit | adql:REAL | Upper limit of a spectral interval covered by the resource. |
The ivoid
column should be an explicit foreign key into
resource
.
It is recommended to maintain indexes on
both the spectral_start
and spectral_end
columns.
As stc_temporal
and stc_spectral
, the
stc_redshift
table associates resources with intervals of
values, in this case with redshifts, given as Δλ/λ (the STC data model's
OPTICAL definition).
Name Utype | Type | Description |
---|---|---|
ivoid vr:Resource.identifier | adql:VARCHAR(*) | The parent resource |
redshift_start stc:AstroCoordArea.RedshiftInterval.LoLimit | adql:REAL | Lower limit of a redshift interval covered by the resource. |
redshift_end stc:AstroCoordArea.RedshiftInterval.LoLimit | adql:REAL | Upper limit of a redshift interval covered by the resource. |
The ivoid
column should be an explicit foreign key into
resource
.
It is recommended to maintain indexes on
both the time_start
and time_end
columns.
No previous versions.