I nternational

V irtual

O bservatory

A lliance

IVOA Registry Relational Schema
Version

Filled in automatically

Working Group:
Registry WG
This version:
filled in automatically
Latest version:
http://www.ivoa.net/Documents/RegTAP/
Previous versions:
None (The schema discussed here started its existence as part of the RegTAP working draft)
Authors:
Markus Demleitner

Abstract

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.

Status of this Document

A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgments

This document has been developed in part with support from the German Astronomical Virtual Observatory (BMBF Bewilligungsnummer 05A08VHA).

Conformance-related definitions

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].

Contents

Introduction

TO BE WRITTEN

The Relational Registry within the VO Architecture

The Relational Registry within the VO architecture

Figure 1: IVOA Architecture diagram with the Relational Registry specification (RegTAP) and the related standards marked up.

This specification directly relates to other VO standards in the following ways:

VOResource, v1.03 std:VOR
VOResource sets the foundation for a formal definition of the data model for resource records via its schema definition. This document refers to concepts laid down there via the utypes given here.
VODataService, v1.1 std:VODS11
VODataService extends the VOResource data model by important concepts and resource types (tablesets, data services, data collections). These concepts and types are reflected in the database schema. Again utypes on the tables and columns link this specification and VODataService.
RegTAP, v1.0
TBW
The IVOA STC data model
TBW

This standard also relates to other IVOA standards:

ADQL, v2.0 std:ADQL
The rules for ingestion are designed to allow easy queries given the constraints of ADQL 2.0. Also, we give three functions that extend ADQL using the language's built-in facility for user-defined functions.

STC Coverage Tables

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

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
TypeDescription
ivoid
vr:Resource.identifier
adql:VARCHAR(*)The parent resource
ra_min
stc:AstroCoordArea.Position2VecInterval.LoLimit2Vec.C1
adql:REALA left edge of a bounding box on the sky the resource covers.
ra_max
stc:AstroCoordArea.Position2VecInterval.HiLimit2Vec.C1
adql:REALAn right edge of a bounding box on the sky the resource covers.
de_min
stc:AstroCoordArea.Position2VecInterval.LoLimit2Vec.C2
adql:REALA lower edge of a bounding box on the sky the resource covers.
de_max
stc:AstroCoordArea.Position2VecInterval.HiLimit2Vec.C2
adql:REALAn 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.

The stc_temporal Table

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
TypeDescription
ivoid
vr:Resource.identifier
adql:VARCHAR(*)The parent resource
time_start
stc:AstroCoordArea.TimeInterval.StartTime
adql:REALLower limit of a time interval covered by the resource.
time_end
stc:AstroCoordArea.TimeInterval.EndTime
adql:REALUpper 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

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
TypeDescription
ivoid
vr:Resource.identifier
adql:VARCHAR(*)The parent resource
spectral_start
stc:AstroCoordArea.SpectralInterval.LoLimit
adql:REALLower limit of a spectral interval covered by the resource.
spectral_end
stc:AstroCoordArea.SpectralInterval.HiLimit
adql:REALUpper 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.

The stc_redshift Table

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
TypeDescription
ivoid
vr:Resource.identifier
adql:VARCHAR(*)The parent resource
redshift_start
stc:AstroCoordArea.RedshiftInterval.LoLimit
adql:REALLower limit of a redshift interval covered by the resource.
redshift_end
stc:AstroCoordArea.RedshiftInterval.LoLimit
adql:REALUpper 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.

ADQL User Defined Functions

TBW

Common Registry queries using STC

TBW

Changes from Previous Versions

No previous versions.

References