I nternational

V irtual

O bservatory

A lliance

IVOA Registry Relational Schema
Version 1.0

IVOA Working Draft 3 December 2013

Working Group:
Registry WG
This version:
Latest version:
Previous versions:
(Unpublished) Internal Working Draft 2013-03-05 (Volute rev. 2011)
(Unpublished) Internal Working Draft 2012-11-12 (Volute rev. 1864)
Markus Demleitner
Paul Harrison
Marco Molinaro
Gretchen Greene
Theresa Dower
Menelaos Perdikeas


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. This specification defines an interface for searching this resource metadata based on the IVOA's TAP protocol. It specifies a set of tables that comprise a useful subset of the information contained in the registry records, as well as the table's data content in terms of the XML VOResource data model. The general design of the system is geared towards allowing easy authoring of queries.

Status of this Document

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

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 [std:RFC2119].


1. Introduction

In the Virtual Observatory (VO), registries provide a means for discovering useful resources, i.e., data and services. Individual publishers offer the descriptions for their resources ("resource records") in publishing registries. At the time of writing, there are roughly 14000 such resource records active within the VO, originating from about 20 publishing registries.

The protocol spoken by these publishing registries, OAI-PMH only allows restricting queries by modification date and identifier and is hence not suitable for data discovery. Even if it were, data discovery would at least be fairly time consuming if each client had to query dozens or, potentially, hundreds of publishing registries.

To enable efficient data discovery nevertheless, there are services harvesting the resource records from the publishing registries and offering rich query languages. The IVOA Registry Interfaces specification [std:RI1] defined, among other aspects of the VO registry system, such an interface using SOAP and an early draft of an XML-based query language.

This document provides an update to the query ("searchable registry") part of that specifiation (chapter 2), aimed towards usage with current VO standards, in particular TAP [std:TAP] and ADQL [std:ADQL]. It follows the model of ObsCore [std:OBSCORE] of defining a representation of a data model within a relational database. In this case, the data model is a simplification of the VO's resource metadata interchange representation, the VOResource XML format [std:VOR]. The simplification yields 13 tables. For each table, TAP_SCHEMA metadata is given together with rules for how to fill these tables from VOResource-serialized metadata records as well as conditions on foreign keys and recommendations on indices.

The resulting set of tables has a modest size by today's standards, but is still non-trivial. The largest table, table_column, has about half a million rows at the time of writing.

The architecture laid out here allows client applications to perform "canned" queries on behalf of their users as well as complex queries formulated directly by advanced users, using the same TAP clients they employ to query astronomical data servers.

The combination of the table set discussed here and a TAP server is referred to in this document as "RegTAP".

1.1. 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 XPaths [std:XPATH].
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 xpaths link this specification and VODataService.
Other Registry Extensions
Registry extensions are VO standards defining how particular resources (e.g., Standards) or capabilities (e.g., IVOA defined interfaces) are described. Most aspects introduced by them are reflected in the res_detail table using xpaths into the registry documents. This document should not in general need updates for registry extension updates. For completeness, we note the versions current as of this specification: SimpleDALRegExt 1.0 [std:DALREGEXT], StandardsRegExt 1.0 [std:STDREGEXT], TAPRegExt 1.0 [std:TAPREGEXT], Registry Interfaces 1.0 [std:RI1].
TAP, v1.0 [std:TAP]
The queries against the schema defined in the present document, and the results of these queries, will usually be transported using the Table Access Protocol TAP. It also allows discovering local additions to the registry relations via TAP's metadata publishing mechanisms.
IVOA Identifiers, v1.12 [std:VOID]
IVOA identifiers are something like the primary keys within the VO registry; as such, they are actual primary keys of the central table of the relational registry. Also, the notion of an authority as laid down in IVOA Identifiers plays an important role as publishing registries can be viewed as a realization of a set of authorities.

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.
This specification will be complemented by a schema of four tables, also under the rr schema making up the relational registry, that gives coverages of resources on the spatial, temporal, spectral and redshift axes. These will be defined in a separate document.

2. Design Considerations

In the design of the tables, the goal has been to preserve as much of VOResource and its extensions, including the element names, as possible.

An overriding consideration has been, however, to make natural joins between the tables behave usefully, i.e., to actually combine rows relevant to the same entity (resource, table, capability, etc.). To disambiguate column names that name the same concept on different entities (name, description, etc.) and would therefore interfere with the natural join, a shortened tag for the source object is prepended to the name. Thus, a description element within a resource ends up in a column named res_description, whereas the same element from a capability becomes cap_description.

We further renamed some columns with respect to their VOResource counterparts to avoid clashes with reserved words in popular database management systems. The alternatives would have been to either recommend quoting them or burden ADQL translation layers with the task of automatically converting them to delimited identifiers. Both alternatives seemed either confusing or impacting robustness.

Furthermore, camel-case identifiers have been converted to underscore-separated ones (thus, standardId becomes standard_id) to have all-lowercase column names; this saves potential headache if users choose to reference the columns using SQL delimited identifiers. Dashes in VOResource attribute names are converted to underscores, too, with the exception of ivo-id, which is just rendered ivoid.

Another design goal of this specification has been that different registries operating on the same set of registry records will return identical responses for most queries; hence, we try to avoid relying on features left not defined by ADQL (e.g., the case sensitivity of string matches). However, with a view to non-uniform support for information retrieval-type queries in database systems, the ivo_hasword user defined function is not fully specified here; queries employing it may yield different results on different implementations, even if they operate on the same set of resource records.

3. Note on case normalization

ADQL has no operators for case-insensitive matching of strings. To allow for robust and straightforward queries nevertheless, most columns containing values not usually intended for display are required to be converted to lower case; in the table descriptions below, there are explicit requirements on case normalization near the end of each section. This is particularly important when the entities to be compared are defined to be case-insensitive (e.g., ucds, IVORNs). Client software that can inspect user-provided arguments (e.g., when filling template queries) should also convert the respective fields to lower case.

This conversion MUST cover all ASCII letters, i.e., A through Z. The conversion SHOULD take place according to algorithm R2 in section 3.13, "Default Case Algorithms" of [std:UNICODE]. In practice, non-ASCII characters are not expected to occur in columns for which lowercasing is required.

Analogously, case-insensitive comparisons as required by some of the user-defined functions for the relational registry MUST compare the ASCII letters without regard for case. They SHOULD compare according to D144 in [std:UNICODE].

4. QNames in VOResource attributes

VOResource and its extensions make use of XML QNames in attribute values, most prominently in xsi:type. The standard representation of these QNames in XML instance documents makes use of an abbreviated notation employing prefixes declared using the xmlns mechanism as discussed in [std:XMLNS]. Within an ADQL-exposed database, no standard mechanism exists that could provide a similar mapping of URLs and abbreviations. The correct way to handle this problem would thus be to have full QNames in the database (e.g., {http://www.ivoa.net/xml/ConeSearch/v1.0}ConeSearch for the canonical cs:ConeSearch). This, of course, would make for excessively tedious and error-prone querying.

For various reasons, VOResource authors have always been encouraged to use a set of "standard" prefixes. This allows an easy and, to users, unsurprising exit from the problem of the missing xmlns declarations: For the representation of QNames within the database, these recommended prefixes are now mandatory. Future VOResource extensions define their mandatory prefixes themselves.

Following the existing practice, minor version changes are not in general reflected in the recommended prefixes—e.g., both VODataService 1.0 and VODataService 1.1 use vs:. For reference, here is a table of XML namespaces and prefixes for namespaces relevant to this specification:


5. XPaths

This specification piggybacks on top of the well-established VOResource standard. This means that it does not define a full data model, but rather something like a reasonably query-friendly view of a partial representation of one. The link between the actual data model, i.e., VOResource and its extensions as defined by the XML Schema documents, and the fields within this database schema, is provided by xpaths, which are here slightly abbreviated for both brevity and generality.

All xpaths given in this specifiation are assumed to be relative to the enclosing vr:Resource element; these are called "resource xpaths" in the following. If resource xpaths are to be applied to an OAI-PMH response, the xpath expression */*/*/oai:metadata/ri:Resource must be prepended to it, with the canonical prefixes from section 4 implied. The resource xpaths themselves largely do not need explicit namespaces since VOResource elements are by default unqualified. Elements and attributes from non-VOResource schemata have the canonical namespace prefixes, which in this specification only applies to several xsi:type attribute names.

Some tables draw data from several different VOResource elements. For those, we have introduced an extended syntax with additional metacharacters (, ), and |, where the vertical bar denotes an alternative and the parentheses grouping. For instance, our notation /(tableset/schema/|)table/ corresponds to the two xpaths /table and /tableset/schema/table.

Within the Virtual Observatory, the link between data models and concrete data representations is usually made using utypes. Since VOResource is directly modelled in XML Schema, the choice of XPath as the bridging formalism is compelling, though, and utypes themselves are not necessary for the operation of a TAP service containing the relational registry. TAP, however, offers fields for utypes in its TAP_SCHEMA. Since they are not otherwise required, this specification takes the liberty of using them to denote the xpaths.

In the metadata for tables and columns below, the utypes given are obtained from the xpaths by simply prepending them with xpath:. To avoid repetition, we allow relative xpaths: when the xpath in a column utype does not start with a slash, it is understood that is must be concatenated with the table utype to obtain the full xpath.

For illustration, if a table has a utype of xpath:/capability/interface/ and a column within this table has a utype of xpath:accessURL/@use, the resulting resource xpath would come out to be /capability/interface/accessURL/@use; to match this in an OAI-PMH response, the xpath would be */*/*/oai:metadata/ri:Resource/capability/interface/accessURL/@use.

While clients MUST NOT rely on these utypes in either TAP_SCHEMA or the metadata delievered with TAP replies, service operators SHOULD provide them, in particular when there are local extensions to the relational registry in their services. Giving xpaths for extra columns and tables helps human interpretation of them at least when the defining schema files are available.

Resource xpaths are also used in the res_details table (section 7.13). These are normal xpaths (although again understood relative to the enclosing Resource element), which, in particular, means that they are case sensitive. On the other hand, to clients they are simply opaque strings, i.e., clients cannot just search for any xpaths into VOResource within res_details.

6. Discovering Relational Registries

The relational registry can be part of any TAP service. The presence of the tables discussed here is indicated by declaring support for the data model Registry 1.0 with the IVORN ivo://ivoa.net/std/RegTAP/vor in the service's capabilities (see [std:TAPREGEXT]). Technically, this entails adding

<dataModel ivo-id="ivo://ivoa.net/std/RegTAP/vor"
  >Registry 1.0</dataModel>

as a child of the capability element with the type {http://www.ivoa.net/xml/TAPRegExt/v1.0}TableAccess.

A client that knows the access URL of one TAP service containing a relational registry can thus discover all other services exposing one. The "Find all TAP endpoints offering the relational registry" example in section 9 shows a query that does this.

It is recommended to additionally register a relational registry as a VODataService data collection and connect this and the TAP services with a pair of service-for/served-by relations. This allows giving more metadata on the data content like, for example, the frequency of harvesting.

Services implementing this data model that do not (strive to) offer the full data content of the VO registry (like domain-specific registries or experimental systems) MUST NOT declare the above data model in order to not invite clients expecting the VO registry to send queries to it.

7. VOResource Tables

In the following table descriptions, the names of tables and columns are normative and MUST be used as given, and all-lowercase. On the values in the utype columns within TAP_SCHEMA, see section 5. All columns defined in this document MUST have a 1 in the std column of the TAP_SCHEMA.table_columns table. Unless otherwise specified, all values of ucd and unit in TAP_SCHEMA.table_columns are NULL for columns defined here. Descriptions are not normative (as given, they usually are taken from the schema files of VOResource and its extensions with slight redaction). Registry operators MAY provide additional columns in their tables, but they MUST provide all columns given in this specification.

All table descriptions start out with brief remarks on the relationship of the table to the VOResource XML data model. Then, the columns are described in a selection of TAP_SCHEMA metadata. For each table, recommendations on explicit primary and foreign keys as well as indexed columns are given, where it is understood that primary and foreign keys are already indexed in order to allow efficient joins; these parts are not normative, but operators should ensure decent performance for queries assuming the presence of the given indices and relationships. Finally, lowercasing requirements (normative) are given.

The following tables make up the data model ivo://ivoa.net/std/RegTAP/vor:

Pieces of behaviour of a resource.
Information on access modes of a capability.
Input parameters for services.
Relationships between resources, e.g., mirroring, derivation, but also providing access to data within a resource.
A date associated with an event in the life cycle of the resource. This could be creation or update. The role column can be used to clarify.
XPath-value pairs for members of resource or capability and their derivations that are less used and/or from VOResource extensions. The pairs refer to a resource if cap_index is NULL, to the referenced capability otherwise.
Entities, i.e., persons or organizations, operating on resources: creators, contacts, publishers, contributors.
Sets of tables related to resources.
Topics, object types, or other descriptive keywords about the resource.
(Relational) tables that are part of schemata or resources.
The resources, i.e., services, data collections, organizations, etc., present in this registry.
Metadata on columns of tables pertaining to resources.
Validation levels for resources and capabilities.

7.1. The resource Table

The rr.resource table contains most atomic members of vr:Resource that have a 1:1 relationship to the resource itself. Members of derived types are, in general, handled through the res_detail table even if 1:1 (see 7.13). The content_level, content_type, waveband, and rights members are 1:n but still appear here. If there are multiple values, they are concatenated with hash characters (#). Use the ivo_hashlist_has ADQL extension function to check for the presence of a single value. This convention saves on tables while not complicating common queries significantly.

A local addition is the creator_seq column. It contains all content of the name elements below a resource element curation child's creator children, concatenated with a sequence of semicolon and blank characters ("; "). The individual parts must be concatenated preserving the sequence of the XML elements. The resulting string is primarily intended for display purposes ("author list") and is hence not case-normalized. It was added since the equivalent of an author list is expected to be a metadatum that is displayed fairly frequently, but also since the sequence of author names is generally considered significant. The res_role table, on the other hand, does not allow recovering the input sequence of the rows belonging to one resource.

The res_type column reflects the lower-cased value of the ri:Resource element's xsi:type attribute, where the canonical prefixes are used. While custom or experimental VOResource extensions may lead to more or less arbitrary strings in that column, VOResource and its IVOA-recommended extensions at the time of writing define the following values for res_type:

A naming authority (these records allow resolving who is responsible for IVORNs with a certain authority; cf. [std:VOID])
A registry is considered a publishing registry if it contains a capability element with xsi:type="vg:Harvest". Old, RegistryInterface 1-compliant registries also use this type with a capability of type vg:Search. The relational registry as specified here, while superceding these old vg:Search capabilities, does not use this type any more. See section 6 on how to locate services supporting it.
The main purpose of an organisation as a registered resource is to serve as a publisher of other resources.
Any entity or component of a VO application that is describable and identifiable by a IVOA Identifier; while it is technically possible to publish such records, the authors of such records should probably be asked to use a more specific type.
A resource that can be invoked by a client to perform some action on its behalf
A service that interacts with one or more specified tables having some coverage of the sky, time, and/or frequency.
A service for accessing astronomical data; publishers choosing this over vs:catalogservice probably intend to communicate that there are no actual sky positions in the tables exposed.
A schema as a logical grouping of data which, in general, is composed of one or more accessible datasets. Use the rr.relationship table to find out services that allow access to the data (the served_by relation), and/or look for values for /accessURL in rr.res_detail.
A description of a standard specification.

The status attribute of vr:Resource is considered an implementation detail of the XML serialization and is not kept here. Neither inactive nor deleted records may be kept in the resource table. Since all other tables in the relational registry should keep a foreign key on the ivoid column, this implies that only metadata on active records is being kept in the relational registry. In other words, users can expect a resource to exist and work if they find it in a relational registry .

adql:VARCHAR(*)Unambiguous reference to the resource conforming to the IVOA standard for identifiers
adql:VARCHAR(*)Resource type (something like vs:datacollection, vs:catalogservice, etc)
adql:TIMESTAMPThe UTC date and time this resource metadata description was created. This timestamp must not be in the future. This time is not required to be accurate; it should be at least accurate to the day. Any insignificant time fields should be set to zero.
adql:VARCHAR(*)A short name or abbreviation given to something. This name will be used where brief annotations for the resource name are required. Applications may use to refer to this resource in a compact display. One word or a few letters is recommended. No more than sixteen characters are allowed.
adql:VARCHAR(*)The full name given to the resource
adql:TIMESTAMPThe UTC date this resource metadata description was last updated. This timestamp must not be in the future. This time is not required to be accurate; it should be at least accurate to the day. Any insignificant time fields should be set to zero.
adql:VARCHAR(*)Description of the content level or intended audience
adql:VARCHAR(*)An account of the nature of the resource.
adql:VARCHAR(*)URL pointing to a human-readable document describing this resource.
adql:VARCHAR(*)The creator(s) of the resource in the order given by the resource record author.
adql:VARCHAR(*)Nature or genre of the content of the resource
adql:VARCHAR(*)The format of source_value. Recognized values include "bibcode", referring to a standard astronomical bibcode (http://cdsweb.u-strasbg.fr/simbad/refcode.html).
adql:VARCHAR(*)A bibliographic reference from which the present resource is derived or extracted.
adql:VARCHAR(*)Label associated with creation or availablilty of a version of a resource.
adql:REALA single numeric value representing the angle, given in decimal degrees, by which a positional query against this resource should be "blurred" in order to get an appropriate match.
adql:VARCHAR(*)A hash-separated list of regions of the electro-magnetic spectrum that the resource's spectral coverage overlaps with.
adql:VARCHAR(*)Information about rights held in and over the resource.

This table should have the ivoid column explicitly set as its primary key.

The following columns MUST be lowercased during ingestion: ivoid, res_type, content_level, content_type, source_format, waveband. Clients are advised to query the res_description and res_title columns using the the ivo_hasword function, and to use ivo_hashlist_has on content_level, content_type, waveband, and rights.

The row for region_of_regard TAP_SCHEMA.tables must have deg in its unit column.

7.2. The res_role Table

This table subsumes the contact, publisher, contributor, and creator members of the VOResource data model. They have been combined into a single table to reduce the total number of tables, and also in anticipation of a unified data model for such entities in future versions of VOResource.

The actual role is given in the base_role column, which can be one of contact, publisher, contributor, or creator. Depending on this value, here are the xpaths for the table fields (we have abbreviated /curation/publisher as cp, /curation/contact as co, /curation/creator as cc, and /curation/contributor as cb):

base_role value contact publisher creator contributor
role_name co/name cp cc/name cb
role_ivoid co/name/@ivo-id cp/@ivo-id cc/name/@ivo-id cb/@ivo-id
address co/address N/A N/A N/A
email co/email N/A N/A N/A
telephone co/telephone N/A N/A N/A
logo co/logo N/A cc/logo N/A

Not all columns are available for each role type in VOResource. For example, contacts have no logo, and creators no telephone members. Unavailable metadata (marked with N/A in the above table) MUST be represented with NULL values in the corresponding columns.

Note that, due to current practice in the VO, it is not easy to predict what role_name will contain; it could be a single name, where again the actual format is unpredictable (full first name, initials in front or behind, or even a project name), but it could as well be a full author list. Thus, when matching against role_names, you will have to use rather lenient regular expressions. Changing this, admittedly regrettable, situation would probably require a change in the VOResource schema.

adql:VARCHAR(*)The parent resource.
adql:VARCHAR(*)The real-world name or title of a person or organization
adql:VARCHAR(*)An IVOA identifier of a person or organization
adql:VARCHAR(*)A mailing address for a person or organization
adql:VARCHAR(*)An email address the entity can be reached at
adql:VARCHAR(*)A telephone number the entity can be reached at
adql:VARCHAR(*)URL pointing to a graphical logo, which may be used to help identify the entity
adql:VARCHAR(*)The role played by this entity; this is one of contact, publisher, and creator

The ivoid column should be an explicit foreign key into the resource table. It is recommended to maintain indexes on at least the role_name column, ideally in a way that supports regular expressions.

The following columns MUST be lowercased during ingestion: ivoid, role_ivoid, base_role. Clients are advised to query the remaining columns, in particular role_name, case-insensitively, e.g., using ivo_nocasematch.

7.3. The res_subject Table

Since subject queries are expected to be frequent and perform relatively complex checks (e.g., resulting from thesaurus queries in the clients), the subjects are kept in a separate table rather than being hash-joined like other string-like 1:n members of resource.

adql:VARCHAR(*)The parent resource.
adql:VARCHAR(*)Topics, object types, or other descriptive keywords about the resource.

The ivoid column should be an explicit foreign key into resource. It is recommended to index the res_subject column, preferably in a way that allows to process case-insensitive and pattern queries using the index.

The ivoid column MUST be lowercased during ingestion. Clients are advised query the res_subject column case-insensitively, e.g., using ivo_nocasematch.

7.4. The capability Table

The capability table describes a resource's modes of interaction; it only contains the members of the base type vr:Capability. Members of derived types are kept in the res_detail table (see 7.13).

The table has an integer-typed column cap_index to disambiguate multiple capabilities on a single resource. Operators are free to choose the actual values as convenient, although it is recommended to just enumerate the capabilities in their physical sequence per-resource.

adql:VARCHAR(*)The parent resource.
adql:SMALLINTRunning number of this capability within the resource.
adql:VARCHAR(*)The type of capability covered here.
adql:VARCHAR(*)A human-readable description of what this capability provides as part of the over-all service
adql:VARCHAR(*)A URI for a standard this capability conforms to.

This table should have an explicit primary key made up of ivoid and cap_index. The ivoid column should be an explicit foreign key into resource. It is recommended to maintain indexes on at least the cap_type and standard_id columns.

The following columns MUST be lowercased during ingestion: ivoid, cap_type, standard_id. Clients are advised to query the cap_description column using the ivo_hasword function.

7.5. The res_schema Table

The res_schema table corresponds to VODataService's schema element. It has been renamed to avoid clashes with the SQL reserved word SCHEMA.

The table has an integer-typed column schema_index to disambiguate multiple schema elements on a single resource. Operators are free to choose the actual values as convenient, although it is recommended to just enumerate the schema elements in their physical sequence per-resource. The xpath count(preceding-sibling::schema) gives one possible set of values for this column; it has not been prescribed via a utype, though, since other enumeration schemes are valid as well.

adql:VARCHAR(*)The parent resource.
adql:SMALLINTA running number for the res_schema rows belonging to a resource.
adql:VARCHAR(*)A free text description of the tableset explaining in general how all of the tables are related.
adql:VARCHAR(*)A name for the set of tables.
adql:VARCHAR(*)A descriptive, human-interpretable name for the table set.
adql:VARCHAR(*)An identifier for a concept in a data model that the data in this schema as a whole represent.

This table should have an explicit primary key made up of ivoid and schema_index. The ivoid column should be an explicit foreign key into resource.

The following columns MUST be lowercased during ingestion: ivoid, schema_name, schema_utype. Clients are advised to query the schema_description and schema_title columns using the the ivo_hasword function.

7.6. The res_table Table

The res_table table models VODataService's table element. It has been renamed to avoid name clashes with the SQL reserved word TABLE.

VODataService 1.0 had a similar element that was a direct child of resource. Ingestors should also accept such tables, as there are still numerous active VODataService 1.0 resources in the Registry at the time of writing (this is the reason for the alternative in the table xpath).

The table contains an integer-typed column table_index to disambiguate multiple tables on a single resource. Operators are free to choose the actual values as convenient, although it is recommended to just enumerate the tables in their physical sequence per-resource (but not per schema—table_index MUST be unique within a resource).

adql:VARCHAR(*)The parent resource.
adql:SMALLINTIndex of the schema this table belongs to, if it belongs to a schema (otherwise NULL).
adql:VARCHAR(*)A free-text description of the table's contents
adql:VARCHAR(*)The fully qualified name of the table. This name should include all catalog or schema prefixes needed to distinguish it in a query.
adql:INTEGERAn artificial counter for the tables belonging to a resource
adql:VARCHAR(*)A descriptive, human-interpretable name for the table
adql:VARCHAR(*)A name for the role this table plays. Recognized values include "output", indicating this table is output from a query; "base_table", indicating a table whose records represent the main subjects of its schema; and "view", indicating that the table represents a useful combination or subset of other tables. Other values are allowed.
adql:VARCHAR(*)An identifier for a concept in a data model that the data in this table as a whole represent.

This table should have an explicit primary key made up of ivoid and table_index. The ivoid column should be an explicit foreign key into resource. It is recommended to maintain an index on at least the table_description column, ideally one suited for queries with ivo_hasword.

The following columns MUST be lowercased during ingestion: ivoid, table_name, table_type, table_utype. Clients are advised to query the table_description and table_title columns using the the ivo_hasword function.

7.7. The table_column Table

The table_column table models the content of VOResource's column element. The table has been renamed to avoid a name clash with the SQL reserved word COLUMN.

Since it is expected that queries for column properties will be fairly common in advanced queries, it is the column table that has the unprefixed versions of common member names (name, ucd, utype, etc).

The flag column contains a concatenation of all values of a column element's flag children, separated by hash characters. Use the ivo_hashlist_has function in queries against flag.

The table_column table also includes information from VODataService's data type concept. VODataService 1.1 includes several type systems (VOTable, ADQL, Simple). The type_system column contains the value of the column's datatype child, with the VODataService XML prefix fixed to vs; hence, this column will contain one of NULL, vs:TAPType, vs:SimpleDataType, and vs:VOTableType.

adql:VARCHAR(*)The parent resource.
adql:INTEGERIndex of the table this column belongs to.
adql:VARCHAR(*)The name of the column.
adql:VARCHAR(*)A unified content descriptor that describes the scientific content of the parameter.
adql:VARCHAR(*)The unit associated with all values in the column.
adql:VARCHAR(*)An identifier for a role in a data model that the data in this column represents.
adql:SMALLINTIf 1, the meaning and use of this parameter is reserved and defined by a standard model. If 0, it represents a database-specific parameter that effectively extends beyond the standard.
adql:VARCHAR(*)The type of the data contained in the column.
adql:VARCHAR(*)An identifier for the schema that the value given by the extended attribute is drawn from.
adql:VARCHAR(*)A custom type for the values this column contains.
adql:VARCHAR(*)The shape of the array that constitutes the value, e.g., 4, *, 4*, 5x4, or 5x*, as specified by VOTable.
adql:VARCHAR(*)The string that is used to delimit elements of an array value when arraysize is not '1'.
adql:VARCHAR(*)The type system used, as a QName with a canonical prefix; this will ususally be one of vs:simpledatatype, vs:votabletype, and vs:taptype.
adql:VARCHAR(*)Hash-separated keywords representing traits of the column. Recognized values include "indexed", "primary", and "nullable".
adql:VARCHAR(*)A free-text description of the column's contents.

The pair ivoid, table_index should be an explicit foreign key into res_table. It is recommended to maintain indexes on at least the column_description, name, ucd, and utype columns, where the index on column_description should ideally be able to handle queries using ivo_hasword.

The following columns MUST be lowercased during ingestion: ivoid, name, ucd, utype, datatype, type_system. Clients are advised to query the description column using the ivo_hasword function, and to query the flag column using the ivo_hashlist_has function.

7.8. The interface Table

The interface table subsumes both the vr:Interface and vr:accessURL types from VOResource. The integration of accessURL into the interface table means that an interface in the relational registry can only have one access URL, where in VOResource it can have many. In practice, this particular VOResource capability has not been used by registry record authors. Since access URLs are probably the item most queried for, it seems warranted to save one indirection when querying for them.

This specification deprecates the maxOccurs="unbounded" in the definition of Interface's accessURL child in the XML schema http://www.ivoa.net/xml/VOResource/v1.0; in future versions of VOResource, implementations can expect this to be maxOccurs="1". Meanwhile, implementation behaviour in the presence of multiple access URLs in an interface is undefined.

The table contains an integer-typed column intf_index to disambiguate multiple interfaces of one resource. Operators are free to choose the actual values as convenient, although it is recommended to just enumerate the interfaces in their physical sequence per resource.

The query_type column is a hash-joined list (analoguos to waveband, etc. in the resource table), as the XML schema allows listing up to two request methods.

This table only contains interface elements from within capabilities. Interface elements in StandardsRegExt records are ignored in RegTAP, and they must not be inserted in this table, since doing so would disturb the foreign key from interface into capability. In other words, RegTAP requires every interface to have a parent capability.

Analogous to resource.res_type, the intf_type column contains type names; VOResource extensions can define new types here, but at the time of writing, the following types are mentioned in IVOA-recommended schemata:

A service invoked via an HTTP query with either form-urlencoded or multipart form-data parameters.
A (form-based) interface intended to be accessed interactively by a user via a web browser.
A standard OAI PMH interface using HTTP queries with form-urlencoded parameters.
A standard OAI PMH interface using a SOAP Web Service interface.
A Web Service that is describable by a WSDL document.
adql:VARCHAR(*)The parent resource.
adql:SMALLINTThe index of the parent capability.
adql:SMALLINTA running number for the interfaces of a resource.
adql:VARCHAR(*)The type of the interface (vr:WebBrowser, vs:ParamHTTP, etc).
adql:VARCHAR(*)An identifier for the role the interface plays in the particular capability. If the value is equal to "std" or begins with "std:", then the interface refers to a standard interface defined by the standard referred to by the capability's standardID attribute.
adql:VARCHAR(*)The version of a standard interface specification that this interface complies with. When the interface is provided in the context of a Capability element, then the standard being refered to is the one identified by the Capability's standardID element.
adql:VARCHAR(*)Hash-joined list of expected HTTP method (GET or POST) supported by the service.
adql:VARCHAR(*)The MIME type of a document returned in the HTTP response.
adql:VARCHAR(*)The location of the WSDL that describes this Web Service. If NULL, the location can be assumed to be the accessURL with '?wsdl' appended.
adql:VARCHAR(*)A flag indicating whether this should be interpreted as a base URL ('base'), a full URL ('full'), or a URL to a directory that will produce a listing of files ('dir').
adql:VARCHAR(*)The URL at which the interface is found.

This table should have the pair ivoid, cap_index as an explicit foreign key into capability, and the pair ivoid, and intf_index as an explicit primary key. Additionally, it is recommended to maintain an index on at least the intf_type column.

The following columns MUST be lowercased during ingestion: ivoid, intf_type, intf_role, std_version, query_type, result_type, url_use. Clients are adviced to query query_type using the the ivo_hashlist_has function.

7.9. The intf_param Table

The intf_param table keeps information on the parameters available on interfaces. It is therefore closely related to table_column, but the differences between the two are significant enough to warrant a separation between the two tables. Since the names of common column attributes are used where applicable in both tables (e.g., name, ucd, etc), the two tables cannot be (naturally) joined.

adql:VARCHAR(*)The parent resource.
adql:SMALLINTThe index of the interface this parameter belongs to.
adql:VARCHAR(*)The name of the parameter.
adql:VARCHAR(*)A unified content descriptor that describes the scientific content of the parameter.
adql:VARCHAR(*)The unit associated with all values in the parameter.
adql:VARCHAR(*)An identifier for a role in a data model that the data in this parameter represents.
adql:SMALLINTIf 1, the meaning and use of this parameter is reserved and defined by a standard model. If 0, it represents a database-specific parameter that effectively extends beyond the standard.
adql:VARCHAR(*)The type of the data contained in the parameter.
adql:VARCHAR(*)An identifier for the schema that the value given by the extended attribute is drawn from.
adql:VARCHAR(*)A custom type for the values this parameter contains.
adql:VARCHAR(*)The shape of the array that constitutes the value, e.g., 4, *, 4*, 5x4, or 5x*, as specified by VOTable.
adql:VARCHAR(*)The string that is used to delimit elements of an array value when arraysize is not '1'.
adql:VARCHAR(*)An indication of whether this parameter is required to be provided for the application or service to work properly (one of required, optional, ignored, or NULL).
adql:VARCHAR(*)A free-text description of the column's contents.

The pair ivoid, intf_index should be an explicit foreign key into interface.

The remaining requirements and conventions are as per section 7.7 where applicable, and param_description taking the role of column_description.

7.10. The relationship Table

The relationship element is a slight denormalization of the vr:Relationship type: Whereas in VOResource, a single relationship element can take several IVORNs, in the relational model, the pairs are stored directly. It is straightforward to translate between the two representations in the database ingestor.

adql:VARCHAR(*)The parent resource.
adql:VARCHAR(*)The named type of relationship; this can be mirror-of, service-for, served-by, derived-from, related-to, or something user-defined.
adql:VARCHAR(*)The URI form of the IVOA identifier for the resource refered to.
adql:VARCHAR(*)The name of resource that this resource is related to.

The ivoid column should be an explicit foreign key into the resoure table. You should index at least the related_id column.

The following columns MUST be lowercased during ingestion: ivoid, relationship_type, related_id.

7.11. The validation Table

The validation subsumes the vr:validationLevel-typed members of both vr:Resource and vr:Capability.

If the cap_index column in NULL the validation comprises the entire resource. Otherwise, only the referenced capability has been validated.

While it is recommended that harvesters only accept resource records from their originating registries, it is valuable to gather validation results from various sources. Hence, harvesters for the relational registry may choose to obtain validation data from the OAI-PMH endpoints of various registries by not harvesting just for the ivo_managed set and generate rr.validation rows from these records. This can trigger potentially problematic behaviour when the original registry updates its resource record in that naive implementations will lose all third-party validation rows; this may actually be the correct behaviour, since an update of the registry record might very well indicate validation-relevant changes in the underlying services. Implementations are free to handle or ignore validation results as they see fit, and they may add validation results of their own.

For convenicence, we repeat the definition of the validation levels from [std:RM]:

The resource has a description that is stored in a registry. This level does not imply a compliant description.
In addition to meeting the level 0 definition, the resource description conforms syntactically to this standard and to the encoding scheme used.
In addition to meeting the level 1 definition, the resource description refers to an existing resource that has been demonstrated to be functionally compliant. When the resource is a service, it is considered to exist and to be functionally compliant if use of the Service.InterfaceURL or Service.BaseURL responds without error when used as intended by the resource. If the service is a standard one, it must also demonstrate the response is syntactically compliant with the service standard in order to be considered functionally compliant. If the resource is not a service, then the ReferenceURL must be shown to return a document without error.
In addition to meeting the level 2 definition, the resource description has been inspected by a human and judged to comply semantically to this standard as well as meeting any additional minimum quality criteria (e.g., providing values for important but non-required metadata) set by the human inspector. [...]
In addition to meeting the level 3 definition, the resource description meets additional quality criteria set by the human inspector and is therefore considered an excellent description of the resource. Consequently, the resource is expected to operate well as part of a VO application or research study.
adql:VARCHAR(*)The parent resource.
adql:VARCHAR(*)The IVOA ID of the registry or organisation that assigned the validation level.
adql:SMALLINTA numeric grade describing the quality of the resource description, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.
adql:SMALLINTIf non-NULL, the validation only refers to the the capability referenced here.

The ivoid should be an explicit foreign key into resource. Note, however, that ivoid, cap_index is not a foreign key into capability since cap_index may be NULL (in case the validation addresses the entire resource).

The following columns MUST be lowercased during ingestion: ivoid, validated_by.

7.12. The res_date Table

The res_date table contains information gathered from vr:Curation's date children.

adql:VARCHAR(*)The parent resource.
adql:TIMESTAMPA date associated with an event in the life cycle of the resource.
adql:VARCHAR(*)A string indicating what the date refers to, e.g., created, availability, updated.

The ivoid column should be an explicit foreign key into resource.

The following columns MUST be lowercased during ingestion: ivoid, value_role.

7.13. The res_detail Table

The res_detail table is RegTAP's primary means for extensibility as well as a fallback for less-used simple metadata. Conceptually, it stores triples of resource entity references, resource xpaths, and values, where resource entities can be resource records themselves or capabilities. Thus, metadata with values that are either string-valued or sets of strings can be represented in this table.

As long as the metadata that needs to be represented in the relational registry for new VOResource extensions is simple enough, no changes to the schema defined here will be neccessary as these are introduced. Instead, the extension itself simply defines new xpaths to be added in res_detail.

Some complex metadata—tr:languageFeature or vstd:key being examples—cannot be kept in this table. If a representation of such information in the relational registry is required, this standard will need to be changed.

Appendix A gives a list of resource xpaths from the registry extensions that were recommendations at the time of writing. For the resource xpaths marked with an exclamation mark there, xpath/value pairs MUST be generated whenever the corresponding metadata items are given in a resource record. For the remaining resource xpaths, these pairs should be provided if convenient; they mostly concern test queries and other curation-type information that, while unlikely to be useful to normal users, may be relevant to curation-type clients that, e.g., ascertain the continued operation of services.

Some detail values must be interpreted case-insensitively; this concerns, in particular, IVORNs like the TAP data model type. For other rows—the test queries are immediate examples—, changing the case will likely break the data. In order to avoid having to give and implement case normalization rules by detail xpath, no case normalization is done on detail values at all, and users and clients will have to use the ivo_nocasematch user defined function (see section 8) when locating case-insensitive values. For the resource xpaths given in Appendix A, this concerns all items with xpaths ending in @ivo-id.

Individual ingestors MAY choose to expose additional metadata using other utypes, provided they are formed according to the rules in section 5 (this rule is intended to minimize the risk of later clashes).

In addition to the metadata listed in this specification, metadata defined in future IVOA-approved VOResource extensions MUST or SHOULD be present in res_details as the extensions require it.

adql:VARCHAR(*)The parent resource.
adql:SMALLINTThe index of the parent capability; if NULL the xpath-value pair describes a member of the entire resource.
adql:VARCHAR(*)The xpath of the data item
adql:VARCHAR(*)(Atomic) value of the member

The ivoid column should be an explicit foreign key into resource. It is recommended to maintain indexes on at least the columns detail_xpath and detail_value, where the indices on detail_value should ideally work for both direct comparisons and searches using the ivo_nocasematch function.

The following column MUST be lowercased during ingestion: ivoid. Clients are advised to use the ivo_nocasematch function to search in detail_value if the values are to be compared case-insensitively (e.g., all IVORNs).

8. ADQL User Defined Functions

TAP Servers implementing the ivo://ivoa.net/std/RegTAP/vor data model MUST implement the following three functions in their ADQL 2.0 language, with signatures written as recommended in [std:TAPREGEXT]:

ivo_nocasematch(value VARCHAR(*), pattern VARCHAR(*))->INTEGER
The function returns 1 if pattern matches value, 0 otherwise. pattern is defined as for the SQL LIKE operator, but the match is performed case-insensitively.
ivo_hasword(haystack VARCHAR(*), needle VARCHAR(*)) -> INTEGER
The function takes two strings and returns 1 if the second is contained in the first one in a "word" sense, i.e., delimited by non-letter characters or the beginning or end of the string, where case is ignored. Additionally, servers MAY employ techniques to improve recall, in particular stemming. Registry clients must hence expect different results from different servers when using ivo_hasword; for such queries trying them on multiple registries may improve recall.
ivo_hashlist_has(haslist VARCHAR(*), item VARCHAR(*))->INTEGER
The function takes two strings; the first is a list of words not containing the hash sign (#), concatenated by hash signs, the second is a word not containing the hash sign. It returns 1 if, compared case-insensitively, the second argument is in the list of words encoded in the first argument. The behaviour for second arguments containing a hash sign is undefined.

Reference implementations of the three functions for the PostgreSQL database system are given in Appendix B.

9. Common Queries to the Relational Registry

This section contains sample queries to the relational registry, mostly contributed as use cases by various members of the IVOA Registry working group. They are intended as an aid in designing relational registry queries, in particular for users new to the data model.

Where these queries locate access URLs of standard services, they contain intf_role='std' conditions. Desktop clients should probably include this to weed out nonstandard interfaces on standard capabilities, which are rare but technically legal; on the other hand, there are fairly standards-compliant interfaces for which the operator neglected to set role="std", and the respective services would be missed with such a condition. Hand-crafted queries can probably typically do without restraining role since most standard capabilities in real-world resources only have one—standard—interface.

TAP accessURLs

Problem: Find all TAP services; return their accessURLs

As the capability type is in rr.capability, whereas the access URL can be found from rr.interface, this requires a join:

SELECT ivoid, access_url 
FROM rr.capability
NATURAL JOIN rr.interface
WHERE standard_id='ivo://ivoa.net/std/tap'
  AND intf_role='std'

Other standard_ids relevant here include:

  • ivo://ivoa.net/std/registry for OAI-PMH services,
  • ivo://ivoa.net/std/sia for SIA services,
  • ivo://ivoa.net/std/conesearch for SCS services, and
  • ivo://ivoa.net/std/ssa for SSA services.

Image Services with Spirals

Problem: Find all SIA services that might have spiral galaxies

This is somewhat tricky since it is probably hard to image a part of the sky guaranteed not to have some, possibly distant, spiral galaxy in it. However, translating the intention into "find all SIA services that mention spiral in either the subject (from rr.res_subject), the description, or the title (which are in rr.resource)", the query would become:

SELECT ivoid, access_url 
FROM rr.capability 
  NATURAL JOIN rr.resource
  NATURAL JOIN rr.interface
  NATURAL JOIN rr.res_subject
WHERE standard_id='ivo://ivoa.net/std/sia'
  AND intf_role='std'
  AND (
    1=ivo_nocasematch(res_subject, '%spiral%')
    OR 1=ivo_hasword(res_description, 'spiral')
    OR 1=ivo_hasword(res_title, 'spiral'))

Infrared Image Services

Problem: Find all SIA services that provide infrared images

The waveband information in rr.resource comes in hash-separated atoms (which can be radio, millimeter, infrared, optical, uv, euv, x-ray, or gamma-ray). For matching those, use the ivo_hashlist_has function as below. The access URL and the service standard come from rr.interface and rr.capability, respectively.

SELECT ivoid, access_url 
FROM rr.capability 
  NATURAL JOIN rr.resource
  NATURAL JOIN rr.interface
WHERE standard_id='ivo://ivoa.net/std/sia'
  AND intf_role='std'
  AND 1=ivo_hashlist_has('infrared', waveband)

Catalogs with Redshifts

Problem: Find all searchable catalogs (i.e., cone search services) that provide a column containing redshifts

Metadata on columns exposed by a service are contained in rr.table_column. Again, this table can be naturally joined with rr.capability and rr.interface:

SELECT ivoid, access_url 
FROM rr.capability 
  NATURAL JOIN rr.table_column
  NATURAL JOIN rr.interface 
WHERE standard_id='ivo://ivoa.net/std/conesearch'
  AND intf_role='std'
  AND ucd='src.redshift'

Sometimes you want to match a whole set of ucds. Frequently the simple regular expressions of SQL will help, as in AND ucd LIKE 'pos.parallax%' . When that is not enough, use boolean OR expressions

Names from an Authority

Problem: Find all the resources published by a certain authority

An "authority" within the VO is something that hands out identifiers. You can tell what authority a record came from by looking at the "host part" of the IVO identifier, most naturally obtained from rr.resource. Since ADQL cannot actually parse URIs, we make do with simple string matching:

SELECT ivoid 
FROM rr.resource
WHERE ivoid LIKE 'ivo://org.gavo.dc%'

Records Published by X

Problem: What registry records are there from a given publisher?

This uses the rr.res_role table both match names (in this case, a publisher that has "gavo" in its name) and to ascertain the named entity actually publishes the resource (rather than, e.g., just being the contact in case of trouble). The result is a list of ivoids in this case. You could join this with any other table in the relational registry to find out more about these services.

SELECT ivoid 
FROM rr.res_role
WHERE 1=ivo_nocasematch(role_name, '%gavo%')
  AND base_role='publisher'

or, if the publisher actually gives its ivo-id in the registry records,

SELECT ivoid 
FROM rr.res_role
WHERE role_ivoid='ivo://ned.ipac/ned'
  AND base_role='publisher'

Records from Registry

Problem: What registry records are there originating from registry X?

This is mainly a query interesting for registry maintainers. Sill, it is a nice example for joining with the rr.res_detail table, in this case to first get a list of all authorities managed by the CDS registry.

SELECT ivoid FROM rr.resource
  SELECT 'ivo://' || detail_value || '%' AS pat FROM rr.res_detail
  WHERE detail_xpath='/managedAuthority' 
    AND ivoid='ivo://cds.vizier/registry') 
  AS authpatterns
ON (resource.ivoid LIKE authpatterns.pat)

Locate RegTAP services

Problem: Find all TAP endpoints offering the relational registry

This is the discovery query for RegTAP services themselves; note how this combines rr.res_detail pairs with rr.capability and rr.interface to locate the desired protocol endpoints.

SELECT access_url
FROM rr.interface
NATURAL JOIN rr.capability
NATURAL JOIN rr.res_detail
WHERE standard_id='ivo://ivoa.net/std/tap'
  AND intf_role='std'
  AND detail_xpath='/capability/dataModel/@ivo-id'
  AND 1=ivo_nocasematch(detail_value, 'ivo://ivoa.net/std/regtap/vor')

TAP with Physics

Problem: Find all TAP services exposing a table with certain features

"Certain features" could be "have some word in their description and having a column with a certain UCD". Either way, this kind of query fairly invariably combines the usual rr.capability and rr.interface for service location with rr.table_column for the column metadata and rr.res_table for properties of tables.

SELECT ivoid, access_url, name, ucd, column_description
FROM rr.capability 
  NATURAL JOIN rr.interface
  NATURAL JOIN rr.table_column
  NATURAL JOIN rr.res_table
WHERE standard_id='ivo://ivoa.net/std/tap'
  AND intf_role='std'
  AND 1=ivo_hasword(table_description, 'quasar')
  AND ucd='phot.mag;em.opt.v'

Theoretical SSA

Problem: Find all SSAP services that provide theoretical spectra

The metadata required to solve this problem is found in the SSAP registry extension and is thus kept in rr.res_detail:

SELECT access_url 
FROM rr.res_detail 
  NATURAL JOIN rr.capability 
  NATURAL JOIN rr.interface 
WHERE detail_xpath='/capability/dataSource' 
  AND intf_role='std'
  AND standard_id='ivo://ivoa.net/std/ssa'
  AND detail_value='theory'

Find Contact Persons

Problem: The service at http://dc.zah.uni-heidelberg.de/__system__/tap/run/tap is down, who can fix it?

This uses the rr.res_role table and returns all information on it based on the IVORN of a service that in turn was obtained from rr.interface. You could restrict to the actual technical contact person by requiring base_role='contact'.

SELECT DISTINCT base_role, role_name, email 
FROM rr.res_role 
  NATURAL JOIN rr.interface 
WHERE access_url='http://dc.zah.uni-heidelberg.de/__system__/tap/run/tap'

Related Capabilities

Problem: Get the capabilities of all services serving a specific resource (typically, a data collection)

In the VO, data providers can register pure data collections without access options (or just furnished with a link to a download). They can then declare that their data can be "served-by" some other resource, typically a TAP service or some collective service for a number of instruments. To locate the access options to the data itself, inspect rr.relationship and use it to select records from rr.capability.

FROM rr.relationship AS a
  JOIN rr.capability AS b 
    ON (a.related_id=b.ivoid) 
WHERE relationship_type='served-by'

A. XPaths for res_details

This appendix defines the of the res_details table (see section 7.13 for details) by giving xpaths for which xpath/value pairs MUST (where marked with an exclamation mark) or SHOULD be given if the corresponding data is present in the resource records. This list is normative for metadata defined in IVOA recommendations current as of the publication of this document (see section 1.1). As laid down in section 7.13, new VOResource extensions or new versions of existing VOResource extensions may amend this list.

The xpaths are suffient for locating the respective metdata as per section 5. With the explanations we give the canonical prefixes for the XML namespaces from which the items originate, which is where further information can be found.

/accessURL (!)
For data collection resources, this is the URL that can be used to download the data contained. Do not enter accessURLs from interfaces into res_detail. (vs).
The hard run time limit, given in seconds (tr).
The category indicating the level to which this instance complies with the SSA standard (ssap).
/capability/creationType (!)
The category that describes the process used to produce the dataset; one of archival, cutout, filtered, mosaic, projection, specialExtraction, catalogExtraction (ssap).
/capability/dataModel (!)
The short, human-readable name of a data model supported by a TAP service; for most applications, clients should rather constrain /capability/dataModel/@ivo-id (tr).
/capability/dataModel/@ivo-id (!)
The IVORN of the data model supported by a TAP service (tr).
/capability/dataSource (!)
The category specifying where the data originally came from; one of survey, pointed, custom, theory, artificial (ssap).
/capability/defaultMaxRecords (!)
The largest number of records that the service will return when the MAXREC parameter is not specified in the query input (ssap).
The run time limit for newly-created jobs, given in seconds (tr).
/capability/imageServiceType (!)
The class of image service: Cutout, Mosaic, Atlas, Pointed (sia).
/capability/language/name (!)
A short, human-readable name of a language understood by the TAP service (tr).
/capability/language/version/@ivo-id (!)
The IVORN of a language supported by a TAP service (tr).
The largest aperture that can be supported upon request via the APERTURE input parameter by a service that supports the special extraction creation method (ssap).
/capability/maxFileSize (!)
The maximum image file size in bytes (sia).
The maximum size in the latitude (Dec.) direction (sia).
The maximum size in the longitude (R.A.) direction (sia).
The image size in the latitude (Dec.) direction in pixels (sia-1.0).
The image size in the longitude (R.A.) direction in pixels (sia-1.0).
A measure of the largest image the service can produce given as the maximum number of pixels along the first or second axes. (sia).
The maximum size in the latitude (Dec.) direction (sia).
The maximum size in the longitude (R.A.) direction (sia).
/capability/maxRecords (!)
The largest number of items (records, rows, etc) that the service will return (cs, sia, vg, ssap).
/capability/maxSearchRadius (!)
The largest search radius, in degrees, that will be accepted by the service without returning an error condition. Not providing this element or specifying a value of 180 indicates that there is no restriction. (ssap)
/capability/maxSR (!)
The largest search radius of a cone search service (cs).
/capability/outputFormat/@ivo-id (!)
An IVORN of an output format (tr).
A short, mnemonic identifier for a service's output format (tr).
/capability/outputFormat/mime (!)
The MIME type of an output format (tr).
The maximal output size for newly-created jobs (tr).
The unit (rows/bytes) in which the service's default output limit is given (tr).
The hard limit of a service's output size (tr).
The unit of this service's hard output limit (tr).
The default time between job creation and removal on this service, given in seconds (tr).
The hard limit for the retention time of jobs on this services (tr).
/capability/supportedFrame (!)
The STC name for a world coordinate system frame supported by this service (ssap).
The catalog to query (cs).
Declination in a test query (cs)
Any extra (non-standard) parameters that must be provided (apart from what is part of base URL given by the accessURL element; cs, sia).
Declination for a SIA test query (sia).
The Declination of the center of the search position in decimal degrees (ssap).
The Right Ascension of the center of the search position in decimal degrees (ssap).
A coordinate system reference frame name for a test query. If not provided, ICRS is assumed (ssap).
The coordinate system reference frame name indicating the frame to assume for the given position (empty means ICRS; ssap).
Fully specified test query formatted as an URL argument list in the syntax specified by the SSA standard. The list must exclude the REQUEST argument (ssap).
Right ascension in a test query (cs)
The size of the search radius in an SSA search query (ssap).
Region size for a SIA test query in declination (sia).
Region size for a SIA test query in RA (sia).
Search radius of a cone search service's test query (cs).
Verbosity of a service's test query (cs, sia).
An advisory size above which user agents should reconfirm uploads to this service (tr).
The unit of the limit specified (tr).
Hard limit for the size of uploads on this service (tr).
The unit of the limit specified (tr).
/capability/verbosity (!)
true if the service supports the VERB keyword; false, otherwise (cs).
/coverage/footprint (!)
A URL of a footprint service for retrieving precise and up-to-date description of coverage (vs).
/coverage/footprint/@ivo-id (!)
The URI form of the IVOA identifier for the service describing the capability refered to by this element (vs).
/deprecated (!)
A sentinel that all versions of the referenced standard are deprectaed. The value is a human-readable explanation for the designation (vstd).
/endorsedVersion (!)
A version of a standard that is recommended for use (vstd).
/facility (!)
The observatory or facility used to collect the data contained or managed by this resource (vs).
/format (!)
The physical or digital manifestation of the information supported by a (DataCollection) resource. MIME types should be used for network-retrievable, digital data, non-MIME type values are used for media that cannot be retrieved over the network (vs).
If true, then an accompanying /format item is a MIME Type. Within res_details, this does not work for services that give more than one format; since furthermore the literal of vs:Format allows a good guess whether or not it is a MIME type, this does not appear a dramatic limitation (vs).
/instrument (!)
The instrument used to collect the data contained or managed by a resource (vr).
/instrument/@ivo-id (!)
IVORN of the instrument used to collect the data contained or managed by a resource (vr).
/managedAuthority (!)
An authority identifier managed by a registry (vg).
/managingOrg (!)
The organization that manages or owns this authority (vr).
/schema/@namespace (!)
An identifier for a schema described by a standard (vstd).

Note that the representation of StandardsRegExt's status and use attributes as well as its key would require sequences of complex objects, which is impossible using res_detail. Hence, the respective metadata is not queriable within the relational registry. Similarly, complex TAPRegExt metadata on languages, user defined functions, and the like cannot be represented in this table. Since these pieces of metadata do not seem relevant to resource discovery and are geared towards other uses of the respective VOResource extensions, a more complex model does not seem warrented just so they can be exposed.

B. The Extra UDFs in PL/pgSQL

What follows are (non-normative) implementations of the three user defined functions specificed in section 8 in the SQL dialect of PostgreSQL (e.g., [doc:Postgres92]).

Note that PostgreSQL cannot use fulltext indices on the respective columns if the functions are defined in this way for (fairly subtle) reasons connected with NULL value handling. While workarounds are conceivable, they come with potentially unwelcome side effects, at least as of PostgreSQL 9.x. It is therefore recommended to replace expressions involving the functions given here with simple boolean expressions in the ADQL translation layer whenever possible.

  CREATE OR REPLACE FUNCTION ivo_hasword(haystack TEXT, needle TEXT)
    SELECT CASE WHEN to_tsvector($1) @@ plainto_tsquery($2) 
      THEN 1 
      ELSE 0 
  $func$ LANGUAGE SQL;

  CREATE OR REPLACE FUNCTION ivo_hashlist_has(hashlist TEXT, item TEXT)
    -- postgres can't RE-escape a user string; hence, we'll have
    -- to work on the hashlist (this assumes hashlist is already
    -- lowercased).
    SELECT CASE WHEN lower($2) = ANY(string_to_array($1, '#'))
      THEN 1 
      ELSE 0 
  $func$ LANGUAGE SQL;

  CREATE OR REPLACE FUNCTION ivo_nocasematch(value TEXT, pattern TEXT)
      THEN 1 
      ELSE 0 
  $func$ LANGUAGE SQL;

C. Implementation notes

This appendix contains a set of constraints and recommendations for implementing the relational registry model on actual RDBMSes, originating partly from an analysis of the data content of the VO registry in February 2013, partly from a consideration of limits in various XML schema documents. This concerns, in particular, minimum lengths for columns of type adql:VARCHAR. Implementations MUST NOT truncate strings of length equal to or smaller than the minimal lengths given here; the limitations are not, however, upper limits, and indeed, when choosing an implementation strategy it is in general preferable to not impose artificial length restrictions, in particular if no performance penalty is incurred.

These notes can also be useful with a view to preparing user interfaces for the relational registry, since input forms and similar user interface elements invariably have limited space; the limits here give reasonable defaults for the amount of data that should minimally be manipulatable by a user with reasonable effort.

The ivoid field present in every table of this specification merits special consideration, on the one hand due to its frequency, but also since other IVOA identifiers stored in the relational registry should probably be treated analoguously. Given that IVORNs in the 2013 data fields have a maximum length of roughly 100 characters, we propose that a maximum length of 255 should be sufficient even when taking possible fragment identifiers into account.

Field type Datatype suggested Pertinent Fields
ivo-id VARCHAR(255) {all_tables}.ivoid
res_detail.detail_value for several values of detail_xpath

The relational registry also contains some date-time values. The most straightforward implementation certainly is to use SQL timestamps. Other relational registry fields that straightforwardly map to common SQL types are those that require numeric values, viz., REAL, SMALLINT, and INTEGER. The following table summarizes these:

Field type Datatype Pertinent Fields
floating point REAL resource.region_of_regard
small integer SMALLINT capability.cap_index

The fields containing Utypes, UCDs, and Units are treated in parallel here. The 2013 registry data indicates a length of 128 characters is sufficient for real-world purposes; actually, at least UCDs and Units could of course grow without limitations, but it seems unreasonable anything longer than a typical line might actually be useful. As far as utypes are concerned, we expect those to shrink rather than grow with new standardization efforts.

In this category, we also summarize our resource xpaths. With the conventions laid down in this document, it seems unlikely that future extensions to VOResource will be so deeply nested that 128 characters will not be sufficient for their resource xpaths.

Field type Datatype suggested Pertinent Fields
VARCHAR(128) res_schema.schema_utype

The relational registry further has an e-mail field, for which we chose 128 characters as a reasonable upper limit (based on a real maximum of 40 characters in the 2013 data). There are furthermore URLs (in addition to access and reference URLs, there are also URLs for the WSDL of SOAP services and logos for roles). Due to the importance of in particular the access URLs we strongly recommend to use non-truncating types here. Empirically, there are access URLs of up to 224 characters in 2013 (reference URLs are less critical at a maximum of 96 characters). Expecting that with REST-based services, URL lengths will probably rather tend down than up, we still permit truncation at 255 characters.

Field type Datatype suggested Pertinent Fields
e-mail VARCHAR(128) res_role.email
URLs VARCHAR(255) resource.reference_url

The next group of columns comprises those that have values taken from a controlled or finite vocabulary. Trying to simplify the view, lengths in the form of powers of two are considered.

Field type Datatype suggested Pertinent Fields
VARCHAR(255) resource.content_level
VARCHAR(64) resource.rights
VARCHAR(32) resource.res_type
VARCHAR(4) interface.query_type

Finally, there are the fields that actually contain what is basically free text. For these, we have made a choice from reasonable powers of two lengths considering the actual lengths in the 2013 registry data. A special case are fields that either contain natural language text (the descriptions) or those that have grown without limit historically (resource.creator_seq, and, giving in to current abuses discussed above, res_role.role_name). For all such fields, no upper limit can sensibly be defined. However, since certain DBMSes (e.g., MySQL older than version 5.6) cannot index fields with a TEXT datatype and thus using VARCHAR may be necessary at least for frequenly-searched fields, we give the maximal length of the fields in the 2013 registry in parentheses after the column designations for the TEXT datatype:

Field type Datatype suggested Interested Fields
free string values TEXT resource.res_description (7801)
resource.creator_seq (712)
res_role.role_name (712)
res_schema.schema_description (934)
res_table.table_description (934)
table_column.description (3735)
intf_param.description (347) capability.cap_description (100)
VARCHAR(255) resource.res_title
VARCHAR(128) resource.version
VARCHAR(64) res_table.table_name
VARCHAR(32) resource.source_format
VARCHAR(16) resource.short_name

D. XSLT to enumerate RegTAP XPaths

The (non-normative) following XSL stylesheet emits RegTAP xpaths as discussed in section 5 when applied to a VOResource extension. Considering readability and limitations of XSLT, this is not fully general -- if VOResource extensions started to inherit from other extensions' subclasses of Resource, Capability, or Interface, this stylesheet will need to be extended.

Still, it is a useful tool when evaluating how to map a given extension to RegTAP.

<stylesheet version="1.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0" xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.1">
<!-- extract RegTAP xpath from VOResource and related XML schema files -->
<!-- This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. For the complete text of the GPL, see http://www.gnu.org/licenses/. -->
<!-- The basic strategy here is: start from all discernible types derived from vr:Resource, vr:Capability, and vr:Interface; we need to handle capability and interface separately since they may not be explicitely reachable from a resource due to the way capability and interface types are declared in VOResource (i.e., through xsi:type). Each root is the start element for a recursion yielding the utypes. During this recursion, attributes yield utypes by concatenating the parent name with the attribute name, and elements yield utypes by concatenating the element name with the parent name. Elements take part in the recursion, where their utype becomes the new parent name. Note that the xpaths generated here are the ones used in the res_details table. For the xpaths used in lieu of utypes in TAP_SCHEMA and VOSI tables, you'll want to make them relative. Hack alert: We need to traverse the type tree; however, due to (practical) limitations of XSLT1, we don't do that across files. So, if a type were to inherit from a class derived from VOResource or Capability in another document, this stylesheet would not notice. Also, we kill all namespace prefixes in attributes. Proper handling of that probably is close to impossible with XSLT1. -->
<output method="text"/>
<strip-space elements="*"/>
<!-- An index used to retrieve the type definitions for the child elements in walk; note that this only spans one file, which is the primary limitation of this program -->
<key name="definitions" match="xs:simpleType|xs:complexType" use="@name"/>
<!-- A map from types to the names of their base classes; this is a bit haphazard since we don't want to use XSLT extensions that actually understand XML schema. A recursion within the type hierarchy takes place in walk-for-type -->
<key name="of-type" match="xs:complexType" use="substring-after(./xs:complexContent/*/@base, ':')"/>
<template name="add-doc">
<!-- retrieve the "short" doc and add them in parens if present, emit an lf either way -->
<if test="boolean(xs:annotation[1])">
<value-of select="concat(' (', normalize-space(xs:annotation[1]/xs:documentation), ')')"/>
<text> </text>
<template name="walk">
<!-- the central (recursive) template building up utypes by collecting subelements; the current node here is a type definition -->
<param name="parent-path"/>
<for-each select="descendant::xs:attribute">
<value-of select="concat($parent-path, '/@', @name)"/>
<call-template name="add-doc"/>
<for-each select="descendant::xs:element">
<!-- capability and interface are roots of their own -->
<if test="@name!='capability' and @name!='interface'">
<value-of select="concat($parent-path, '/', @name)"/>
<call-template name="add-doc"/>
<variable name="child-type" select="substring-after(@type, ':')"/>
<if test="key('definitions', $child-type)">
<variable name="child-path" select="concat($parent-path, '/', @name)"/>
<for-each select="key('definitions', $child-type)">
<call-template name="walk">
<with-param name="parent-path" select="$child-path"/>
<!-- collect attributes and elements for our node from the types we are derived from, too -->
<for-each select="descendant::xs:extension|descendant::xs:restriction">
<for-each select="key('definitions', substring-after(@base, ':'))">
<call-template name="walk">
<with-param name="parent-path" select="$parent-path"/>
<template name="walk-for-type">
<!-- iterates over the types and elements derived from base-type -->
<param name="base-type"/>
<param name="parent-path"/>
<for-each select="key('of-type', $base-type)">
<call-template name="walk">
<with-param name="parent-path" select="$parent-path"/>
<call-template name="walk-for-type">
<with-param name="base-type" select="@name"/>
<with-param name="parent-path" select="$parent-path"/>
<!-- templates cover the immediate types; the derived types are handled in explicit call-templates in the the template for root below. -->
<template match="//xs:complexType[@name='Resource']">
<call-template name="walk">
<with-param name="parent-path" select="'Resource'"/>
<template match="//xs:complexType[@name='Capability']">
<call-template name="walk">
<with-param name="parent-path" select="'Capability'"/>
<template match="//xs:complexType[@name='Interface']">
<call-template name="walk">
<with-param name="parent-path" select="'Interface'"/>
<template match="/">
<call-template name="walk-for-type">
<with-param name="base-type" select="'Resource'"/>
<with-param name="parent-path" select="''"/>
<call-template name="walk-for-type">
<with-param name="base-type" select="'Capability'"/>
<with-param name="parent-path" select="'/capability'"/>
<call-template name="walk-for-type">
<with-param name="base-type" select="'Interface'"/>
<with-param name="parent-path" select="'/capability/interface'"/>
<template match="text()"/>
<!-- vi:et:sw=2:sta -->

E. Changes from Previous Versions

E.1. Changes from WD-20130909

  • Updates for REC of SimpleDALRegExt, which contains versions 1.1 of both the sia and the ssap XML schemas; thisi means there are now additional namespace URIs to take into accound, as well as new res_detail xpaths /capability/maxSearchRadius, /capability/maxImageSize, and /testQuery/pos/refframe.
  • Reinstated makeutypes.xslt script; it's useful even with the new xpaths.

E.2. Changes from WD-20130411

  • The final utype reform: most of our ex-utype strings aren't called utypes any more, they're fairly plain xpaths. Consequently, res_detail.detail_utype has been renamed res_detail.detail_xpath.
  • Renamed some columns and the subject table to relieve the need of quoting in MS SQL Server (or, in the case or use_param, maintain consistency after the renaming):
  • rr.intf_param grew the arraysize and delim columns that before accidentally were only present in rr.table_column.
  • Added warnings about having to match case-insensitively in res_detail.detail_value for IVORN-valued rows.
  • Restored the foreign key from interface to capability. Mandating ignoring interface elements from StandardsRegExt records really is the lesser evil.
  • resource.region_of_regard now must have unit metadata declared.
  • We now explicitely deprecate multiple access urls per interface and announce that single access URLs will be enforced in future VOResource versions.

E.3. Changes from WD-20130305

  • intf_index is now required to be unique within a resource, not a capability; this is because StandardsRegExt has interfaces outside of capabilities. In consequence, the intf_param no longer has a cap_index column, and its foreign key is just ivoid and intf_index.
  • Added handling for the StandardsRegExt schema element.
  • The list of res_details utypes was moved to an appendix since it was too long to be included in the running text.
  • Redation for WD publication.

E.4. Changes from WD-20121112

  • Adapted all utypes to better match future VO-DML utypes.
  • footprint, data_url, facility, and instrument are no longer in rr.resource but are instead kept in rr.res_details rows.
  • For VOResource compliance, intf_param has no flag column any more.
  • res_role.base_utype is renamed to res_role.base_role and no longer pretends to be a utype fragments; also, the content is now a simple word..
  • intf_param.use is now called intf_param.use_param to avoid possible clashes with reserved SQL words.
  • Removed all material on STC coverage.
  • Added an appendix recommending field sizes.


[std:RI1] Kevin Benson, Ray Plante, Elizabeth Auden, Matthew Graham, Gretchen Greene, Martin Hill, Tony Linde, Dave Morris, Wil O'Mullane, Guy Rixon, Aurélien Stébé, and Kona Andrews, Kevin Benson and Ray Plante, editors.
IVOA registry interfaces version 1.0. IVOA Recommendation, 2009.
[std:RFC2119] S Bradner.
Key words for use in RFCs to indicate requirement levels. RFC 2119, March 1997.
[std:XMLNS] Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin, and Henry S. Thompson.
Namespaces in XML 1.0 (third edition). W3C Recommendation, December 2009.
[std:XPATH] James Clark and Steve DeRose.
Xml path language (xpath), version 1.0. W3C Recommendation, 1999.
[std:UNICODE] The Unicode Consortium.
The unicode standard, version 6.1 core specification, 2012.
[std:TAPREGEXT] Markus Demleitner, Patrick Dowler, Ray Plante, Guy Rixon, and Mark Taylor.
TAPRegExt: a VOResource schema extension for describing TAP services, version 1.0. IVOA Recommendation, August 2012.
[std:TAP] Patrick Dowler, Guy Rixon, and Doug Tody.
Table access protocol version 1.0. IVOA Recommendation, March 2010.
[std:RM] Robert Hanisch, IVOA Resource Registry Working Group, and NVO Metadata Working Group, R Hanisch, editor.
Resource metadata for the virtual observatory. IVOA Recommendation, 2007.
[std:STDREGEXT] Paul Harrison, Douglas Burke, Ray Plante, Guy Rixon, and Dave Morris.
StandardsRegExt: a VOResource schema extension for describing IVOA standards, version 1.0. IVOA Recommendation, May 2012.
[doc:Postgres92] http://www.postgresql.org/docs/9.2/static/index.html.
PostgreSQL 9.2.1 documentation. [Online].
[std:OBSCORE] Mireille Louys, Francois Bonnarel, David Schade, Patrick Dowler, Alberto Micol, Daniel Durand, Doug Tody, Laurent Michel, Jesus Salgado, Igor Chilingarian, Bruno Rino, Juan de Dios Santander, and Petr Skoda, Doug Tody, Alberto Micol, Daniel Durand, and Mireille Louys, editors.
Observation data model core components and its implementation in the Table Access Protocol, version 1.0. IVOA Recommendation, 2011.
[std:ADQL] Iñaki Ortiz, Jeff Lusted, Pat Dowler, Alexander Szalay, Yuji Shirasaki, Maria A. Nieto-Santisteba, Masatoshi Ohishi, William O'Mullane, Pedro Osuna, the VOQL-TEG, and the VOQL Working Group, Pedro Osuna and Iñaki Ortiz, editors.
IVOA astronomical data query language. IVOA Recommendation, 2008.
[std:VOR] Raymond Plante, Kevin Benson, Matthew Graham, Gretchen Greene, Paul Harrison, Gerard Lemson, Tony Linde, Guy Rixon, and Aurélien Stébé.
VOResource: an XML encoding schema for resource metadata version 1.03. IVOA Recommendation, February 2008.
[std:DALREGEXT] Raymond Plante, Jesus Delago, Paul Harrison, and Doug Tody.
SimpleDALRegExt: Describing simple data access services, version 1.0. IVOA Proposed Recommendation, May 2012.
[std:VOID] Raymond Plante, Tony Linde, Roy Williams, and Keith Noddle.
IVOA identifiers, version 1.03. IVOA Recommendation, March 2007.
[std:VODS11] Raymond Plante, Aurélien Stébé, Kevin Benson, Patrick Dowler, Matthew Graham, Gretchen Greene, Paul Harrison, Gerard Lemson, Tony Linde, and Guy Rixon.
VODataService: a VOResource schema extension for describing collections and services version 1.1. IVOA Recommendation, December 2010.