<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" type="text/css" href="http://www.ivoa.net/misc/ivoa_doc.css"/><link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" type="text/css" href="http://www.ivoa.net/misc/ivoa_wd.css"/><style xmlns="http://www.w3.org/1999/xhtml" type="text/css">
div#versionstatement, div#dateline {
color: #005A9C;
font-size: 150%;
}
p.parsep {
overflow: hidden;
height: 0pt;
margin-top:0.5ex;
margin-bottom:0.5ex;
}
div.admonition {
width: 30em;
position: relative;
float: right;
background-color: #dddddd;
font-size: 80%;
margin: 1ex;
padding: 3pt;
overflow: auto;
}
p.admonition-type {
background-color: #444444;
color: #ffffff;
margin-top: 0px;
padding-left: 5pt;
padding-top: 5pt;
padding-bottom: 5pt;
font-weight: bold;
}
a.tth_citation, a.tth_citeref {
color: #002A5C;
text-decoration: none;
}
.xmlel {
font-family: monospace;
font-style: italic;
}
.vorent {
font-variant: small-caps;
}
table {
border-collapse: collapse;
border-spacing: 0px;
}
table.tabular {
margin-top: 2ex;
margin-bottom: 1ex;
margin-left: 0.5em;
}
table.tabular > * > tr > td, table.tabular > tr > td {
border-top: 1pt solid gray;
border-bottom: 1pt solid gray;
padding: 2pt;
}
dt {
margin-top: 0.5ex;
}
.redaction {
background-color: #ffff33;
}
span.nolinkurl {
font-family: monospace;
}
.basicstyle__footnotesize {
font-size: 80%;
}
</style>
<meta name="GENERATOR" content="TtH 4.08"/>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8"/>
</head>
<div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<div><table xmlns="http://www.w3.org/1999/xhtml" cellspacing="0" cellpadding="0" width="450"><tr><td><a href="http://www.ivoa.net/"><img height="169" alt="IVOA" src="http://www.ivoa.net/icons/IVOA_wb_300.jpg" width="300" border="0"/></a></td><td><div style="padding: 3.6pt 7.2pt;"><p><b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);"><span> </span>I</span></i></b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);">nternational</span></i></p><p><b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);"><span> </span>V</span></i></b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);">irtual</span></i></p><p><b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);"><span> </span><span> </span>O</span></i></b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);">bservatory</span></i></p><p><b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);">A</span></i></b><i><span style="font-size: 14pt; color: rgb(0, 90, 156);">lliance</span></i><i/></p></div><i/></td></tr></table><br xmlns="http://www.w3.org/1999/xhtml"/></div><h1 xmlns="http://www.w3.org/1999/xhtml">Registry Interfaces </h1><div xmlns="http://www.w3.org/1999/xhtml" id="versionstatement">
Version 1.1</div><div xmlns="http://www.w3.org/1999/xhtml" id="dateline">IVOA Working Draft <span xmlns="" id="docdate">2016-04-13</span></div><dl xmlns="http://www.w3.org/1999/xhtml" id="docmeta"><dt>Working Group</dt><dd xmlns="" id="ivoagroup">Registry WG</dd><dt>This Version</dt><dd><a class="currentlink" href="http://www.ivoa.net/documents/RegistryInterface/20160413">http://www.ivoa.net/documents/RegistryInterface/20160413</a></dd><dt>Latest Version</dt><dd><a class="latestlink" href="http://www.ivoa.net/documents/RegistryInterface">http://www.ivoa.net/documents/RegistryInterface</a></dd><dt>Previous Versions</dt><dd><ul class="previousversions"><li xmlns="" class="previousversion">
<a href="http://www.ivoa.net/documents/RegistryInterface/20091104/">IVOA Registry Interfaces 1.0, IVOA Recommendation 2009-11-04</a></li></ul></dd><dt>Author(s)</dt><dd><ul class="authors"><li xmlns="" class="author">Theresa Dower</li><li xmlns="" class="author">Markus Demleitner</li><li xmlns="" class="author">Kevin Benson</li><li xmlns="" class="author">Ray Plante</li><li xmlns="" class="author">Elizabeth Auden</li><li xmlns="" class="author">Matthew Graham</li><li xmlns="" class="author">Gretchen Greene</li><li xmlns="" class="author">Martin Hill</li><li xmlns="" class="author">Tony Linde</li><li xmlns="" class="author">Dave Morris</li><li xmlns="" class="author">Wil O`Mullane</li><li xmlns="" class="author">Guy Rixon</li><li xmlns="" class="author">Aur\'elien St\'eb\'e</li><li xmlns="" class="author">Kona Andrews</li></ul></dd><dt>Editor(s)</dt><dd><ul class="editors"><li xmlns="" class="editor">Theresa Dower</li><li xmlns="" class="editor">Markus Demleitner</li></ul></dd><dt>Version Control</dt><dd>Revision 3393, last change
2016-05-08 04:05:14 -0400 (Sun, 08 May 2016)<br/><a href="https://volute.g-vo.org/svn/trunk/projects/registry/RegistryInterface/RegistryInterface.tex">Source file in VCS</a></dd></dl>
<div id="abstract"><h2>Abstract</h2>
The VO Registry provides a mechanism with which VO applications can discover
and select resources that are relevant for a particular scientific problem. This specification defines the operation of this system. It is based on a general,
distributed model composed of searchable and publishing registries, as introduced at the beginning of this document. The main body of the specification has two components: (a) an interface for harvesting publishing registries, which builds upon the Open Archives Initiative Protocol for Metadata Harvesting. (b) A VOResource extension for registering registry services and description of a central list of said IVOA registry services.
Finally, this specification briefly discusses client interfaces to
the Registry as provided by searchable registries.
</div>
<h2>Status of this Document</h2>
<p xmlns="http://www.w3.org/1999/xhtml" id="statusdecl"><em>
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".
</em></p>
<h1>Contents </h1><a href="#tth_sEc1">1 Introduction</a><br/>
<a href="#tth_sEc1.1">1.1 Registry Architecture and Definitions</a><br/>
<a href="#tth_sEc1.2">1.2 The Registry Interface within the VO Architecture</a><br/>
<a href="#tth_sEc2">2 The IVOA Harvesting Interface</a><br/>
<a href="#tth_sEc2.1">2.1 The OAI Protocol for Metadata Harvesting</a><br/>
<a href="#tth_sEc2.2">2.2 Metadata Formats for Resource Descriptions</a><br/>
<a href="#tth_sEc2.3">2.3 Identifiers in OAI Messages</a><br/>
<a href="#tth_sEc2.4">2.4 Required Records</a><br/>
<a href="#tth_sEc2.5">2.5 The Identify Operation</a><br/>
<a href="#tth_sEc2.6">2.6 IVOA Supported Sets</a><br/>
<a href="#tth_sEc2.7">2.7 Time Granularity</a><br/>
<a href="#tth_sEc3">3 Registering Registries</a><br/>
<a href="#tth_sEc3.1">3.1 The Authority Resource Extension and the Publishing Process</a><br/>
<a href="#tth_sEc3.2">3.2 Describing Registries with the Registry Resource Extension</a><br/>
<a href="#tth_sEc3.3">3.3 The Search Capability</a><br/>
<a href="#tth_sEc3.4">3.4 The Harvesting Capability</a><br/>
<a href="#tth_sEc4">4 Discovering Registries</a><br/>
<a href="#tth_sEc4.1">4.1 The Registry of Registries</a><br/>
<a href="#tth_sEc4.2">4.2 Harvesting the Registry of Registries</a><br/>
<a href="#tth_sEc5">5 Searching the Registry</a><br/>
<a href="#tth_sEcA">A The RegistryInterface Schema</a><br/>
<a href="#tth_sEcB">B The VORegistry Schema</a><br/>
<a href="#tth_sEcC">C Changes from Previous Versions</a><br/>
<a href="#tth_sEcD">D Changes from Version 1.0</a><br/>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc1"/><h2>
1 Introduction</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="introduction">
</a>In the Virtual Observatory (VO), registries provide a means for
discovering useful resources, i.e., data and services. This discovery
takes place by searching within structured descriptions of resources,
the resource records, authored by the data providers. In order to avoid
a single point of failure for the VO, the Registry is distributed.
This means that each data provider can run a service injecting
resource records into the Registry (a "publishing registry" as defined
below), and anyone can run services that allow global discovery (a
"searchable registry" as defined below).
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
To enable this, common mechanisms for registry communication and
interaction are required.
This document therefore describes the standard interfaces that enable
interoperable registries. Through these interfaces, registry
builders have a common way of sharing resource descriptions with users,
applications, and other registries.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This specification does not cover interfaces for global discovery, which
are the subject of other IVOA standards. Also, service operators are
free to build interactive, end-user interfaces in
any way that best serves their target community.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc1.1"/><h3>
1.1 Registry Architecture and Definitions</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="arch">
</a>A <em>registry</em> is first a repository of structured descriptions of
resources. In the VO, a <em>resource</em> is defined by the IVOA
Recommendation "Resource Metadata for the Virtual Observatory"
<a href="#std:RM" id="CITEstd:RM" class="tth_citation">
(Hanisch et al., 2007)</a> as being
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<blockquote><div>a general term referring to a VO element that can be
described in terms of who curates or maintains it and which can be
given a name and a unique identifier. Just about anything can be a
resource: it can be an abstract idea, such as sky coverage or an
instrumental setup, or it can be fairly concrete, like an organization
or a data collection.
</div></blockquote>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Organizations, data collections, and services can be considered
classes of resources. The most important type of resource to
applications is a service that actually does something. A registry
(lower case),
then, is "a service for which the response is a structured description
of resources"
<a href="#std:RM" class="tth_citeref">
(Hanisch et al., 2007)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This specification is based on the general IVOA model for registries
<a href="#2004ASPC..314..585P" id="CITE2004ASPC..314..585P" class="tth_citation">
(Plante et al., 2004)</a>, which builds on
<a href="#std:RM" class="tth_citeref">
Hanisch et al. (2007)</a>'s model
for resources. In the registry model, the VO environment features
different types of registries that serve different functions. The
primary distinction is between publishing registries and searchable
ones. A secondary distinction is full versus partial.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
A <em>searchable registry</em> is one that allows users and client
applications to search for resource records using selection criteria
against the metadata contained in the records. The purpose of this type
of registry is to aggregate descriptions of many resources distributed
across the network. By providing a single place to locate data and
services, applications are spared from having to visit many different
sites to just to determine which ones are relevant to the scientific
problem at hand. A searchable registry gathers its descriptions from
across the network through a process called <em>harvesting</em>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
A <em>publishing registry</em> is one that simply exposes its resource
descriptions to the VO environment in a way that allows those
descriptions to be harvested. The contents of these registries tend to
be limited to resources maintained by one or a few providers and thus
are local in nature; for example, a data center will run its own
publishing registry to allow other VO components to gather metadata on
the data center's published services.
Since the purpose is simply publishing and not to serve
users and applications directly, it is not necessary to support full
searching capabilities. This simplifies the requirements for a
publishing registry:
storage, management, and indexing of the records can be simpler, as
there is no need to support a
search interface facilitating complex discovery queries.
While a searchable registry in practice will necessitate the
use of a database system, a simple publishing registry may get by
storing its records as flat files on disk.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Note that some registries can play both roles; that is, a searchable
registry may also publish its own resource descriptions.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
A secondary distinction is full versus local. A <em>full registry</em> is
one that attempts to contain records of all resources known to the VO.
Several such registries exist, run by various VO projects. A
<em>local registry</em>, on the other hand, contains only a subset of
known resources. While for publishing registries this subset usually is
defined by what services are maintained by the registry's operator,
other selection criteria are conceivable. For instance, the IVOA's
Education IG is considering running a registry only containing resources
manually selected for suitability for primary and secondary education.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
As mentioned above, harvesting is the mechanism by which a registry can
collect resource records from other registries. It is used by full
registries to aggregate resource records from publishing
registries. It can also be used to synchronize two registries to ensure
that they have the same contents. Harvesting, in this specification, is
modeled as a pull operation between two registries. The term
<em>harvester</em> refers to the registry that wishes to receive records
(usually a searchable registry); it sends its request to the
<em>harvestee</em> (usually a publishing registry), which responds with
the records. Harvesting is a much simpler process than a fully-featured
search interface, as only very few constraints need to be supported and
only full records are being transmitted in responses.
Consequently, different protocols are employed for the
two types of registry operations.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
In this text, "registry" in lower case refers to concrete services,
while "Registry" (or "VO Registry") in upper case refers to the
combination of the set of all resource records and the interfaces to
query and manage them.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc1.2"/><h3>
1.2 The Registry Interface within the VO Architecture</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:rolewithinivoa">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_fIg1">
</a>
<div style="text-align:center"><img src="archdiag.png" alt="archdiag.png"/>
<div style="text-align:center">Figure 1: IVOA Architecture
diagram with the Registry Interface specification (RI) and
the related standards marked up.</div>
<a id="fig:arch">
</a>
</div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This specification directly relates to other VO standards in the
following ways:
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<div class="bigdescription">
<dl>
<dt><b>VOResource
<a href="#std:VOR" id="CITEstd:VOR" class="tth_citation">
(Plante et al., 2008)</a></b></dt>
<dd>VOResource sets the foundation for a
formal definition of the data model for resource records via its schema
definition.</dd>
<dt><b>IVOA Identifiers</b></dt>
<dd>IVOA identifiers are something like the
primary keys to the VO 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.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</dd>
</dl></div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2"/><h2>
2 The IVOA Harvesting Interface</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="harvesting">
</a>The harvesting interface allows the retrieval of complete VOResource
records from registries supporting harvesting. Publishing registries
MUST support the IVOA harvesting interface, searchable registries SHOULD
do so.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The IVOA harvesting interface is built on the standard Protocol for
Metadata Harvesting developed by the Open Archives Initiative, OAI-PMH
<a href="#std:OAIPMH" id="CITEstd:OAIPMH" class="tth_citation">
(Lagoze et al., 2002)</a>. In this section, after giving a brief introduction
to OAI-PMH, we define additional constraints and requirements for
OAI-PMH services to be interoperable with the VO environment.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Version 1.1 of this document drops support of the SOAP
variant of OAI-PMH defined in version 1.0.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.1"/><h3>
2.1 The OAI Protocol for Metadata Harvesting</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="oaipmh">
</a>While for details of OAI-PMH we refer to
<a href="#std:OAIPMH" class="tth_citeref">
Lagoze et al. (2002)</a>,
in the following we give a
brief overview of OAI-PMH that should be sufficient to understand the
protocol's role within the Registry interface architecture.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The OAI-PMH v2.0 specification defines:
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<ul>
<li> the meaning and behavior of the six harvesting operations, referred
to as verbs,
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> the meaning of the input arguments for each operation, and
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> the XML Schema used to encode response messages.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
</ul>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The six standard operations laid down in OAI-PMH are:
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<div class="bigdescription">
<dl>
<dt><b>Identify</b></dt>
<dd> provides a description of the registry</dd>
<dt><b>ListIdentifiers</b></dt>
<dd>returns a list of identifiers for the resource
records held by the registry, possibly restricted to records changed
within a certain time span or to those belonging to a certain set.</dd>
<dt><b>ListRecords</b></dt>
<dd>returns complete resource records in the registry,
possibly restricted to records changed within a certain time span or to
those belonging to a certain set.</dd>
<dt><b>GetRecord</b></dt>
<dd>returns a single resource description matching a given
identifier.</dd>
<dt><b>ListMetadataFormats</b></dt>
<dd>returns a list of supported formats that the
registry can use to encode resource descriptions upon a harvester's
request.</dd>
<dt><b>ListSets</b></dt>
<dd>returns a list of set names supported by the registry
that harvesters can request in order to get back a subset of the
descriptions held by the registry.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</dd>
</dl></div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The ListRecords and GetRecord operations return the actual resource
description records held by the registry. These descriptions are encoded
in XML and wrapped in a general-purpose envelope defined by the OAI-PMH
XML Schema (with the namespace
<tt>http://www.openarchives.org/OAI/2.0</tt>).
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Through the operations' arguments, OAI-PMH provides a number of useful
features:
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<ul>
<li> Support for multiple return formats. As suggested by the existence
of the
<i>ListMetadataFormats</i> operation, a harvester can request the
formats available for encoding returned resource descriptions.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Harvesting by date. The <i>ListIdentifiers</i> and
<i>ListRecords</i> operations both support <tt>from</tt> and
<tt>until</tt> date arguments which restrict the response to records
changed withing the given, possibly half-open, interval.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Harvesting by category. The <i>ListIdentifiers</i> and
<i>ListRecords</i> operations both support a set argument for
retrieving resources that are grouped in a particular category. Resource
records may belong to multiple sets.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Marking records as deleted. Registries may mark records as deleted
so that harvesters will be notified that a resource has become
unavailable even if only performing incremental harvests.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Support for resumption tokens. If a request results in returning a
very large number of records, the registry can choose to split the
results over several calls; this is done by passing a resumption token
back to the harvester. The harvester uses it to retrieve the next set of
matching results.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
</ul>
It is important to note that the OAI-PMH interface is not intended
to be a general search interface. The filtering capabilities described
above are just enough to support intelligent harvesting between
registries. Most end-user applications will use a dedicated search
interface on a searchable registry (cf. sect. <a href="#sect:searching">5</a>).
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
In addition to basic OAI-PMH compliance, this specification defines
a set of OAI-PMH-compliant requirements and recommendations
special to OAI-PMH's use within the VO that are described in the
remaining subsections.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.2"/><h3>
2.2 Metadata Formats for Resource Descriptions</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:metadataformats">
</a>All IVOA registries that support the Harvesting Interface must support
two standard metadata formats: the OAI Dublin Core format (mandated by
the base OAI-PMH standard) and the IVOA VOResource metadata format
<a href="#std:VOR" class="tth_citeref">
(Plante et al., 2008)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The VOResource metadata format has the metadata prefix name
<tt>ivo_vor</tt>, which can be used wherever
<a href="#std:OAIPMH" class="tth_citeref">
Lagoze et al. (2002)</a> allows a
metadata prefix name. The format uses the VOResource core XML Schema
with the namespace <tt>http://www.ivoa.net/xml/VOResource/v1.0</tt>
(recommended namespace prefix <span class="xmlel">vr:</span>) along with any legal
extension of this schema to encode the resource descriptions within the
OAI-PMH metadata tag from the OAI XML Schema (namespace
<tt>http://www.openarchives.org/OAI/2.0</tt>, recommended namespace
prefix <span class="xmlel">oai:</span>).
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
As VOResource and its extensions do not define global elements, the
child element within <span class="xmlel">oai:metadata</span> needs to be separately
defined. This specification does this by providing the
<span class="xmlel">ri:Resource</span> element. It is defined in a schema with the target
namespace
<span class="nolinkurl">http://www.ivoa.net/xml/RegistryInterface/v1.0</span>, which is given
in appendix <a href="#app:rischema">A</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The
<span class="xmlel">ri:Resource</span> element MUST include an <span class="xmlel">xsi:type</span> attribute
that assigns the element's type to <span class="xmlel">vr:Resource</span> or one of its
legal extensions.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
It is strongly recommended that all QName values of <span class="xmlel">xsi:type</span>
attributes within the VOResource record use XML namespace prefixes as
recommended in VOResource or the VOResource extensions. Minor version
changes are not in general reflected in the recommended prefixes -
e.g., both VODataService 1.0 and VODataService 1.1 use <span class="xmlel">vs:</span>.
Registry operators
who must deliver OAI-PMH decuments containing resource records written
to different versions of a registry extension are advised to
override the prefix
bindings on the element level if at all possible.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The OAI Dublin Core format, with the metadata prefix of <tt>oai_dc</tt>,
is defined by the OAI-PMH base standard and must be supported by all
OAI-PMH compliant registries. <span class="redaction">Ray has an XSL that makes oai\_dc
from ivo\_vor -- maybe include that in an appendix?</span>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Harvestable registries may support other metadata formats. Responses to
the
<i>ListMetadataFormats</i> operation
must list all names for formats supported
by the registry; even though they are mandatory, this list must include
<tt>ivo_vor</tt> and <tt>oai_dc</tt>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.3"/><h3>
2.3 Identifiers in OAI Messages</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="oaiidentifiers">
</a>In accordance with the OAI-PMH standard, an OAI-PMH XML envelope that
contains a resource description must include a globally unique URI that
identifies that resource record. This identifier must be the IVOA
identifier used to identify the resource being described as given in
its <span class="xmlel">vr:identifier</span> child element.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This specification does not follow the recommendation of the OAI-PMH
standard with regard to record identifiers. OAI-PMH makes a distinction
between the resource record containing resource metadata and the
resource itself; thus, it recommends that the identifier in the OAI
envelope be different from the resource identifier. In particular, the
former is the choice of the publishing registry. This allows one to
distinguish resource descriptions of the same resource from different
registries, which in principle could be different.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
In the VO, because it is intended that resource descriptions of the
same resource from different registries should not differ (apart from
possible additions of <span class="xmlel">vr:validationLevel</span> elements), there
is not a strong need to distinguish between the resource and the
resource description.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
By making the resource and resource record
identifiers the same, it becomes much easier to retrieve the record for
a single resource via <i>GetRecord</i>, regardless of which
registry is being queried. Otherwise - when the registry chooses
the record identifier - a client will not a priori know the record
identifier for a particular resource, and so it is left to call
<i>ListRecords</i> and search through the metadata of all the
records itself to find the one of interest. In contrast, IVOA
identifiers are intended to be a cross-application way of referring to a
resource, and thus when a client wants only a single specific resource
record, it is very likely that it would know the resource identifier
when making a call to the <i>GetRecord</i> operation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.4"/><h3>
2.4 Required Records</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="oairequired">
</a>This section describes the records that a harvestable VO registry
must include among those it emits via the OAI-PMH operations.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The harvestable registry MUST return one record that describes the
registry itself as a whole, and the <tt>ivo_vor</tt> format MUST be
supported for this record. This record is also included in the
<i>Identify</i> operation response. When encoded using the
<tt>ivo_vor</tt> format, the returned <span class="xmlel">ri:Resource</span> element must
be of the type <span class="xmlel">vg:Registry</span> from the VORegistry schema
(see sect. <a href="#sect:vgharvest">3.4</a>). The
record MUST include a <span class="xmlel">vg:managedAuthority</span> for every authority
identifier that originates at that registry.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Additions to the list of a registry's managed authorities must follow
the protocol outlined in sect. <a href="#sect:authres">3.1</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The harvestable registry must be able to return exactly one record in
<tt>ivo_vor</tt> for each authority identifier listed as a
<span class="xmlel">vg:managedAuthority</span> in the <span class="xmlel">vg:Registry</span> record
that describes that registry. When encoded in the <tt>ivo_vor</tt>
format, the type of these elements must be <span class="xmlel">vg:Authority</span>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.5"/><h3>
2.5 The Identify Operation</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:oaiidentify">
</a>The <i>Identify</i> operation describes the harvestable registry as a
whole. The response from this operation must include all information
required by the OAI-PMH standard. In particular, it must include an
<span class="xmlel">oai:baseURL</span> element that must refer to the base URL to the
harvesting interface endpoint. The <i>Identify</i> response must
include an <span class="xmlel">oai:description</span> element containing a single
<span class="xmlel">ri:Resource</span> element with an <span class="xmlel">xsi:type</span> attribute that
sets the element's type to <span class="xmlel">vg:Registry</span>. The content of
<span class="xmlel">vg:Registry</span> type must be the registry description of the
harvestable registry itself.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
In its <i>Identify</i> response, an OAI-PMH-compliant registry must
declare its support for deleted records. This can be one of
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<dl>
<dt><b><tt>no</tt></b></dt>
<dd> - the registry will never notify harvesters of
records that have become unvailable. In an enviroment like the VO,
where searchable regiestries frequently harvest publishing registries,
this is severely discouraged, as without deleted records, harvesters
need to perform full harvests every time or risk delivering stale
records.</dd>
<dt><b><tt>transient</tt></b></dt>
<dd> - the registry will notify harvesters of
records that have become unavailable, but the deleted records will
entirely vanish after some time. This specification adds to the OAI-PMH
requirements that registries declaring <tt>transient</tt> support MUST
keep their deleted records for at least six months (after which they may
discard them).</dd>
<dt><b><tt>persistent</tt></b></dt>
<dd> - the registry promises to indefinitely keep
deleted records.</dd>
</dl>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.6"/><h3>
2.6 IVOA Supported Sets</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="supportedsets">
</a>Sets, as defined in the OAI-PMH standard, are "an optional construct
for grouping items for the purpose of selective harvesting" (see
<a href="#std:OAIPMH" class="tth_citeref">
Lagoze et al. (2002)</a>, section 2.6). Harvestable IVOA registries are free
to define any number of custom sets for categorizing records. The
OAI-PMH standard allows a record to be a member of multiple sets.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This specification defines one reserved set name with a special
meaning; future versions of this specification may define additional set
names. These reserved set names will all start with the characters
<tt>ivo_</tt>; implementors should not define their own set names
that begin with this string. While support for sets is optional
in the OAI-PMH standard, a VO registry MUST support
the set with the reserved name <tt>ivo_managed</tt> to be compliant
with this specification.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The <tt>ivo_managed</tt> set refers to all records that originate from the
queried registry. That is, those records that were harvested from other
registries are excluded. The Resource identifiers given in the
records MUST have an authority identifier that matches on one of the
<span class="xmlel">vg:managedAuthority</span> values in the <span class="xmlel">vg:Registry</span>
record for that registry. Full searchable registries may use this set
to avoid getting duplicate records when harvesting from many
registries.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc2.7"/><h3>
2.7 Time Granularity</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:timegranularity">
</a>Datestamps in the OAI-PMH 2.0 standard are encoded using ISO8601 and expressed in UTC, with the UTC designator "z" appended to seconds-based granularity where supplied, i.e. <tt>YYYY-MM-DDThh:mm:ssZ</tt>. In general OAI-PMH registries, granularity at seconds scale is optional. Harvestable IVOA registries MUST report datestamps at the granularity of seconds and accept "from" and üntil" arguments in the same format. This simplifies the incremental harvesting process in the multi-registry IVOA environment.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc3"/><h2>
3 Registering Registries</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="regreg">
</a>Harvesting registries must able to locate remote registry resources relevant to them,
and both harvesting registries and clients need access to metadata for the registry service itself. We address both of these issues by providing a schema for describing registries themselves, and a repository for indexing them.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The resource specification for registries defines a VOResource extension schema called
VORegistry, which describes provenance of the registry itself and its support for various interfaces described in this document or elsewhere. These VORegistry resources may themselves be stored as records in registries; each publishing registry MUST contain a self-descriptive VORegistry resource. VORegistry resources also include a list of naming authorities, where each represents a registry publisher's claim of ownership of an authority identifier. From each identifier, further IVOA identifiers for individual service or other records belonging under that publishing umbrella may be created. A publishing registry is said to exclusively manage a naming authority on behalf of the owning publisher; this means that within the IVOA registry network, only that specific registry may publish records having identifiers which begin with that authority identifier.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The XML namespace URI of this schema is
<span class="nolinkurl">http://www.ivoa.net/xml/VORegistry/v1.0</span>.
It has been chosen to allow it to be resolved as a URL to the XML Schema document, which is also given in appendix <a href="#app:vgschema">B</a>. The recommended prefix for this namespace is <span class="xmlel">vg:</span>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The schema has not been changed from the one used in version 1.0,
although the standard contents have somewhat changed. The rationale for
keeping the schema is that some schema features being no longer relevant has no
detrimental consequences for Registry operations, whereas breaking clients with
a change of the schema and XML namespace URI might have.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc3.1"/><h3>
3.1 The Authority Resource Extension and the Publishing Process</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:authres">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_fIg2">
</a> <div xmlns="http://www.w3.org/1999/xhtml" class="language_XML"><pre xmlns="">
<ri:Resource status="active" xsi:type="vg:Authority"
updated="2006-07-01T09:00:00" created="2006-07-01T09:00:00">
<title>IVOA Naming Authority</title>
<shortName>IVOA</shortName>
<identifier>ivo://ivoa.net</identifier>
<curation>
<publisher ivo-id="ivo://ivoa.net/IVOA">International Virtual
Observatory Alliance</publisher>
<creator>
<name>Raymond Plante</name>
<logo>http://www.ivoa.net/icons/ivoa_logo_small.jpg</logo>
</creator>
<date>2006-07-01</date>
<contact>
<name>IVOA Resource Registry Working Group</name>
<email>registry@ivoa.net</email>
</contact>
</curation>
<content>
<subject>virtual observatory</subject>
<description>This registers the IVOA as the owner of the ivoa.net
authority identifier.</description>
<referenceURL>http://rofr.ivoa.net</referenceURL>
</content>
<managingOrg>International Virtual Observatory Alliance</managingOrg>
</ri:Resource>
</pre></div>
#1A sample <span class="xmlel">vg:Authority</span>-typed resource record as it would
be delivered within <span class="xmlel">oai:metadata</span>. XML namespace declarations
are for the prefixes <span class="xmlel">ri:</span>, <span class="xmlel">xsi:</span>, and <span class="xmlel">vg:</span> are
assumed on enclosing elements.
<a id="fig:authrecord">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The <span class="xmlel">vg:Authority</span> type extends the core <span class="xmlel">vr:Resource</span>
type to specifically describe the ownership of an authority identifier
by a publishing organization.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The IVOA identifier of a <span class="xmlel">vg:Authority</span> record provided via the
<span class="xmlel">vr:identifier</span> element must have an empty resource key component
as defined in
<a href="#std:VOID" id="CITEstd:VOID" class="tth_citation">
Plante et al. (2007)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The meaning of a <span class="xmlel">vg:Authority</span> record is that the organization
referenced in the <span class="xmlel">vg:managingOrg</span> element has the sole right to
create (in collaboration with a publishing registry) and register
resource descriptions using the authority identifier given by the
<span class="xmlel">vr:identifier</span> element.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Before a publisher can create resource descriptions using a new
authority identifier, it must first register its claim to the authority
identifier by creating a <span class="xmlel">vg:Authority</span> record. Before the
publishing registry commits the record for export, it must first search
a full registry to determine if a <span class="xmlel">vg:Authority</span> with this
identifier already exists; if it does, the publishing of the new
<span class="xmlel">vg:Authority</span> record must fail.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
When a registry creates a
<span class="xmlel">vg:Authority</span> record, it is said that the registry manages the
associated authority identifier (on behalf of the owning publisher)
because only that registry may create records with identifiers using
that authority identifier. It must also document that fact by adding
a corresponding <span class="xmlel">vg:managedAuthority</span> element to the registry's
own resource record.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The mechanism outlined here is not race-free in the distributed
environment of the VO Registry. The IVOA Registry Working group
periodically monitors the registry-authority graph to ensure each
authority in the Registry is claimed by exactly one registry.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc3.2"/><h3>
3.2 Describing Registries with the Registry Resource Extension</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:resext">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_fIg2">
</a> <div xmlns="http://www.w3.org/1999/xhtml" class="language_XML"><pre xmlns="">
<ri:Resource status="active" xsi:type="vg:Registry"
updated="2015-02-05T20:28:40Z" created="2006-07-01T09:00:00Z">
<title>IVOA Registry of Registries</title>
<shortName>RofR</shortName>
<identifier>ivo://ivoa.net/rofr</identifier>
<curation>(elided)</curation>
<content>
<subject>virtual observatory</subject>
<description>(elided)</description>
<referenceURL>http://rofr.ivoa.net</referenceURL>
<type>Registry</type>
</content>
<capability xsi:type="vg:Harvest"
standardID="ivo://ivoa.net/std/Registry">
<interface xsi:type="vg:OAIHTTP" version="1.0" role="std">
<accessURL>http://rofr.ivoa.net/oai</accessURL>
</interface>
<maxRecords>0</maxRecords>
</capability>
<full>false</full>
<managedAuthority>ivoa.net</managedAuthority>
</ri:Resource>
</pre></div>
#1A sample <span class="xmlel">vg:Registry</span>-typed resource record as it would
be delivered within <span class="xmlel">oai:metadata</span>, including a harvest capability.
XML namespace declarations
are for the prefixes <span class="xmlel">ri:</span>, <span class="xmlel">xsi:</span>, and <span class="xmlel">vg:</span> are
assumed on enclosing elements.
<a id="fig:regrecord">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The <span class="xmlel">vg:Registry</span> type extends the core <span class="xmlel">vr:Service</span> type to
specifically describe registries in order to support discovering them
and collecting their metadata; in addition, the extension type also
defines the VO-specific metadata in the response to an OAI-PMH
<i>Identify</i> request.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
As a subclass of <span class="xmlel">vr:Service</span>, the <span class="xmlel">vg:Registry</span>
type uses <span class="xmlel">vr:capability</span> elements to describe its support for
network interfaces to the services. The specific types defined here
derive from an intermediate restriction on <span class="xmlel">vr:Capability</span> called
<span class="xmlel">vg:RegCapRestriction</span> to force the value of the
<span class="xmlel">standardID</span> attribute to be
<span class="nolinkurl">ivo://ivoa.net/std/Registry</span>.
When the schema will be revised, it is planned to change
this <span class="xmlel">standardID</span>
to refer to a fragment within the standard's resource record. In
particular, OAI-PMH endpoints as specified here will be identified by
<span class="nolinkurl">ivo://ivoa.net/std/Registry#OAI-2.0</span>. Client writers are
advised to write their discovery routines accordingly.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
If the <span class="xmlel">vg:full</span> element in an <span class="xmlel">vg:Registry</span> instance
is set to <tt>true</tt>, it indicates the registry's intent to
accept all valid resource records it harvests from other
registries in accordance with the OAI-PMH specification. This will
typically be searchable registries implementing some Registry search
interface, but there are use cases for full registries just implementing
OAI-PMH (and thus just providing an <span class="xmlel">vg:Harvest</span> capability), too.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The <span class="xmlel">vg:managedAuthority</span> is used by publishing registries to
claim an authority identifier (see also sect. <a href="#oairequired">2.4</a>). Note
that for each managed authority claimed, the registry MUST provide a
<span class="xmlel">vg:Authority</span>-typed resource record for that authority identifier
within its <tt>ivo_managed</tt> set.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
As of version 1.1 of this specification, VO registries must provide
the three mandatory VOSI capabilities: availability, a listing of service capabilities, and a listing of tables if relevant.
<a href="#std:VOSI" id="CITEstd:VOSI" class="tth_citation">
(Grid and Web Services Working Group, 2011)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc3.3"/><h3>
3.3 The Search Capability</h3>
<a id="sect:vgsearch">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Version 1 of this standard defined a search interface, and such
interfaces are described by capabilites of the type <span class="xmlel">vg:Search</span>.
Since in this version, search interfaces are specified by external
standards, such external standards may define differing ways of
discovering them<a href="#tthFtNtAAB" id="tthFrefAAB"><sup>1</sup></a>. The search capability nevertheless is not removed
from the schema in order to allow operators to register RI1 registries
without having to support different versions of the VORegistry schema.
Also, the type may be useful when other registry search interfaces want to
define capability types of their own.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc3.4"/><h3>
3.4 The Harvesting Capability</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:vgharvest">
</a>A registry declares itself to be a harvestable registry by including a
<span class="xmlel">vr:capability</span> element with an <span class="xmlel">xsi:type</span>
attribute set to <span class="xmlel">vg:Harvest</span>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
A <span class="xmlel">vr:capability</span> element of type <span class="xmlel">vg:Harvest</span> MUST
include at least one <span class="xmlel">vr:interface</span> element with an
<span class="xmlel">xsi:type</span> attribute set to <span class="xmlel">vg:OAIHTTP</span> and the
<span class="xmlel">role</span> attribute set to <tt>std</tt>. If the
<span class="xmlel">vr:capability</span> element is used to simultaneously describe
support for other versions of this Registry Interface standard, then the
<span class="xmlel">vr:interface</span> element describing support for this version must
include the version attribute set to <tt>1.0</tt>. The
<span class="xmlel">vr:accessURL</span> element must be set to the base URL for the
OAI-PMH interface.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The <span class="xmlel">vg:OAISOAP</span> extension of <span class="xmlel">vr:WebService</span>
was used by version 1 of this specification and is no longer part of VO
Registry interfaces.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc4"/><h2>
4 Discovering Registries</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc4.1"/><h3>
4.1 The Registry of Registries</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:rofr">
</a>To facilitate discovery and automated harvesting of registries containing VOResource records, a registry serving as a master list of IVOA registries exists as part of the IVOA web infrastructure, hosted at
<span class="nolinkurl">http://rofr.ivoa.net</span>. It is referred to as the Registry of Registries, or RofR (pronounced "rover"). As the RofR is itself a registry, an OAI-PMH interface is provided which conforms to this document. The OAI-PMH interface is always available at
<span class="nolinkurl">http://rofr.ivoa.net/oai</span>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The Registry of Registries includes the VOResource records directly representing each currently active registry of IVOA resources, be they fully searchable or publishing registries providing only an OAI-PMH harvesting interface. These resources are of type <span class="xmlel">vg:Registry</span> as defined in section <a href="#sect:resext">3.2</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Once a registry provider has deployed a new publishing registry, they can register it with the RofR by visiting the web page at
<span class="nolinkurl">http://rofr.ivoa.net/regvalidate</span>. This page presents a simple form into which the provider can enter the URL endpoint for the registry's OAI harvesting interface. The validation check it runs includes schema validation for the OAI interface itself and all resources it lists through the GetRecord method, along with various checks including authority/identifier compliance. Once a publishing registry is validated, the provider has the option to automatically have the registry's self-descriptive VOResource record included in the RofR using the results of the registry's OAI Identify operation. Note that registry validation can be checked without including a publishing registry in the RofR or updating an existing registry listing in the RofR; validation may be run for testing purposes only. Local updates within a publishing registry post-inclusion in the RofR are not necessarily automatically validated by the RofR software.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The Registry of Registries also contains the canonical VOResource descriptions of the most recent versions of VOResource standards and extensions themselves, which are of type <span class="xmlel">vstd:Standard</span>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc4.2"/><h3>
4.2 Harvesting the Registry of Registries</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:harvestrofr">
</a>Given the Registry of Registries contains records for all other currently active and validated IVOA registries, a client wishing to harvest the contents of all registries should begin at the RofR. Fully searchable registries wishing to include records from the other IVOA registries count among these potential clients. To harvest the entire contents of IVOA registries, it is recommended to first harvest the Registry of Registries via its OAI-PMH interface.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
This first step is done by making a call to the RofR's OAI-PMH interface with the<b>ListRecords</b> operation, with the <b>set</b> argument set to <b>ivo_publishers</b>. This will return the registry records (i.e. resources with xsi:type='vg:Registry') for the registries that successfully registered themselves as described in <a href="#sect:rofr">4.1</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The next step in harvesting the entire distributed IVOA registry contents is to iterate over the <span class="xmlel">accessURL</span> of each <span class="xmlel">vg:Registry</span> record's <span class="xmlel">vr:capability</span> of type <span class="xmlel">vg:Harvest</span>, and use the url for each of those OAI-PMH interfaces to harvest the individual registries. This filtering of RofR contents can be done by adding the <tt>set</tt> parameter to an OAI query to the RofR: registries in the RofR comprise the supported set <tt>ivo_publishers</tt>. Then when harvesting each registry in turn, to avoid harvesting duplicate records from the fully searchable registries, it is recommended to add the <tt>set</tt> parameter to that OAI query: records specifically published by a registry which also has a search interface comprise that registry's supported set <tt>ivo_managed</tt>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The very first time the harvester executes the <b>ListRecords</b> operation on the RofR or any listed registry, the <b>from</b> argument should be not used so that all known publishing registries are returned, as well as all known resources within each discovered registry. If the harvesting client wishes to use the OAI interface for incremental updates, it can cache at least a mapping of the registry identifiers to their respective harvesting endpoints along with a timestamp for when this operation was last successfully carried out on each. Then, at the start of subsequent harvesting updates, the harvester can provide the cached date using the <b>from</b> argument to receive only new and updated records, and update the cached timestamp upon success. It is suggested that harvesting clients perform full updates without the <b>from</b> parameter on an occasional basis.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
For example, to get a listing of registries in the IVOA ecosystem, one would first query
<span class="nolinkurl">http://rofr.ivoa.net/oai?verb=ListRecords&metadataPrefix=ivo_vor&set=ivo_publishers</span>. Then, for each returned resource, the <span class="xmlel">accessURL</span> under a <span class="xmlel">Capability</span> with <span class="xmlel">xsi:type=vg:Harvest</span>, that URL could be called as such:
<span class="nolinkurl">http://accessURLValue?verb=ListRecords&metadataPrefix=ivo_vor</span> or
<span class="nolinkurl">http://accessURLValue?verb=ListRecords&metadataPrefix=ivo_vor&from=YYYY-MM-DD</span> for return visits, with YYYY-MM-DD representing the last successful query to that accessURL.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEc5"/><h2>
5 Searching the Registry</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:searching">
</a>Experience with version 1 of this specification suggests that it is
preferable to not couple the relatively stable standards for harvesting and
general registry maintenance with client interfaces to the registry,
which were found to be in much more need of experimentation. For a
discussion of the history of client interfaces in the VO, see
<a href="#paper:regclient" id="CITEpaper:regclient" class="tth_citation">
Demleitner et al. (2015)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
One second-generation standard search interface to the VO Registry that
has progressed to become an IVOA recommendation is RegTAP
<a href="#std:RegTAP" id="CITEstd:RegTAP" class="tth_citation">
(Demleitner et al., 2013)</a>, an interface based on a relational representation of
major parts of VOResource and the VO's TAP protocol
<a href="#std:TAP" id="CITEstd:TAP" class="tth_citation">
(Dowler et al., 2010)</a>.
RegTAP services have been made available from several registry providers listed in the Registry of Registries.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEcA"/><h2>
A The RegistryInterface Schema</h2>
<a id="app:rischema">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The following schema defines a global element, allowing the inclusion of
VOResource records into <span class="xmlel">oai:metadata</span> elements in OAI-PMH
responses for the <tt>ivo_vor</tt> metadata prefix. See
sect. <a href="#sect:metadataformats">2.2</a> for details.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The schema is unchanged from version 1.0 of this specification and
therefore does not change its version.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<div xmlns="http://www.w3.org/1999/xhtml" class="language_XML">
<pre xmlns=""><?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.ivoa.net/xml/RegistryInterface/v1.0"
xmlns:ri="http://www.ivoa.net/xml/RegistryInterface/v1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
elementFormDefault="qualified"
version="1.0">
<xs:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0"/>
<xs:element name="VOResources">
<xs:annotation>
<xs:documentation>
a container for one or more resource descriptions or
identifier references to resources.
</xs:documentation>
<xs:documentation>
This is used to transmit multiple resource descriptions
resulting from a query.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element ref="ri:Resource"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="identifier" type="vr:IdentifierURI"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="from" type="xs:positiveInteger" use="required" />
<xs:attribute name="numberReturned" type="xs:positiveInteger"
use="required" />
<xs:attribute name="more" type="xs:boolean" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="Resource" type="vr:Resource">
<xs:annotation>
<xs:documentation>
a description of a single resource
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>
</pre>
</div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEcB"/><h2>
B The VORegistry Schema</h2>
<a id="app:vgschema">
</a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
The following schema defines VOResource types for describing registries
in the Registry. It is unchanged from version 1.0 of this specification
and therefore does not change its version.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
Note that standards defining search interfaces may specify alternative
or complementary methods of registering the services defined by them.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<div xmlns="http://www.w3.org/1999/xhtml" class="language_XML">
<pre xmlns=""><?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.ivoa.net/xml/VORegistry/v1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
xmlns:vg="http://www.ivoa.net/xml/VORegistry/v1.0"
xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1"
elementFormDefault="unqualified" attributeFormDefault="unqualified"
version="1.0wd">
<xs:annotation>
<xs:appinfo>
<vm:schemaName>VORegistry</vm:schemaName>
<vm:schemaPrefix>xs</vm:schemaPrefix>
<vm:targetPrefix>vg</vm:targetPrefix>
</xs:appinfo>
<xs:documentation>
An extension to the core resource metadata (VOResource) for
describing registries and authority IDs.
</xs:documentation>
</xs:annotation>
<xs:import namespace="http://www.ivoa.net/xml/VOResource/v1.0"
schemaLocation="http://www.ivoa.net/xml/VOResource/v1.0"/>
<xs:complexType name="Registry">
<xs:annotation>
<xs:documentation>
a service that provides access to descriptions of resources.
</xs:documentation>
<xs:documentation>
A registry is considered a publishing registry if it
contains a capability element with xsi:type="vg:Harvest".
It is considered a searchable registry if it contains a
capability element with xsi:type="vg:Search".
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:Service">
<xs:sequence>
<xs:element name="full" type="xs:boolean">
<xs:annotation>
<xs:documentation>
If true, this registry attempts to collect all resource
records known to the IVOA.
</xs:documentation>
<xs:documentation>
A registry typically collects everything by harvesting
from all registries listed in the IVOA Registry of
Registries.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="managedAuthority" type="vr:AuthorityID"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
an authority identifier managed by the registry.
</xs:documentation>
<xs:documentation>
Typically, this means the AuthorityIDs that originated
(i.e. were first published by) this registry. Currently,
only one registry can lay claim to an AuthorityID via
this element at a time.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="RegCapRestriction" abstract="true">
<xs:annotation>
<xs:documentation>
an abstract capability that fixes the standardID to the
IVOA ID for the Registry standard.
</xs:documentation>
<xs:documentation>
See vr:Capability for documentation on inherited children.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="vr:Capability">
<xs:sequence>
<xs:element name="validationLevel" type="vr:Validation"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="description" type="xs:token"
minOccurs="0"/>
<xs:element name="interface" type="vr:Interface"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="standardID" type="vr:IdentifierURI"
use="required" fixed="ivo://ivoa.net/std/Registry"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Harvest">
<xs:annotation>
<xs:documentation>
The capabilities of the Registry Harvest implementation.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vg:RegCapRestriction">
<xs:sequence>
<xs:element name="maxRecords" type="xs:int">
<xs:annotation>
<xs:documentation>
The largest number of records that the registry search
method will return. A value greater than one implies
that an OAI continuation token will be provided when
the limit is reached. A value of zero or less
indicates that there is no explicit limit and
thus, continuation tokens are not supported.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Search">
<xs:annotation>
<xs:documentation>
The capabilities of the Registry Search implementation.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vg:RegCapRestriction">
<xs:sequence>
<xs:element name="maxRecords" type="xs:int">
<xs:annotation>
<xs:documentation>
The largest number of records that the registry search
method will return. A value of zero or less indicates
that there is no explicit limit.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="extensionSearchSupport"
type="vg:ExtensionSearchSupport">
<xs:annotation>
<xs:documentation>
the level of support provided for searching against
metadata defined in a legal VOResource extension schema.
</xs:documentation>
<xs:documentation>
A legal VOResource extension schema is one that imports
and extends the VOResource core schema in compliance
with the VOResource standard.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="optionalProtocol" type="vg:OptionalProtocol"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
the name of an optional advanced search protocol
supported.
</xs:documentation>
<xs:documentation>
Only one optional protocol is currently allowed
(XQuery). It is assumed that the required protocols
(simple keyword search and ADQL) are supported.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="ExtensionSearchSupport">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="core">
<xs:annotation>
<xs:documentation>
Only searches against the core VOResource metadata are
supported.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="partial">
<xs:annotation>
<xs:documentation>
Searches against some VOResource extension metadata are
supported but not necessarily all that exist in the registry.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="full">
<xs:annotation>
<xs:documentation>
Searches against all VOResource extension metadata contained
in the registry are supported.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OptionalProtocol">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="XQuery">
<xs:annotation>
<xs:documentation>
the XQuery (http://www.w3.org/TR/xquery/) protocol as defined
in the VO Registry Interface standard.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="OAIHTTP">
<xs:annotation>
<xs:documentation>
a description of the standard OAI PMH interface using HTTP
(GET or POST) queries.
</xs:documentation>
<xs:documentation>
the accessURL child element is the base URL for the OAI
service as defined in section 3.1.1 of the OAI PMH
standard.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:Interface">
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OAISOAP">
<xs:annotation>
<xs:documentation>
a description of the standard OAI PMH interface using a SOAP
Web Service interface.
</xs:documentation>
<xs:documentation>
the accessURL child element is the service port location URL for
the OAI SOAP Web Service.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:WebService">
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Authority">
<xs:annotation>
<xs:documentation>
a naming authority; an assertion of control over a
namespace represented by an authority identifier.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:Resource">
<xs:sequence>
<xs:element name="managingOrg" type="vr:ResourceName">
<xs:annotation>
<xs:documentation>
the organization that manages or owns this authority.
</xs:documentation>
<xs:documentation>
In most cases, this will be the same as the Publisher.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
</pre>
</div>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEcC"/><h2>
C Changes from Previous Versions</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="sect:changes">
</a>For pre-REC-1.0 changes, see
<a href="#std:RI1" id="CITEstd:RI1" class="tth_citation">
Benson et al. (2009)</a>.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tth_sEcD"/><h2>
D Changes from Version 1.0</h2>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="changes-1.0">
</a>
<ul>
<li> Added requirement for OAI-PMH interface to support seconds granularity, optional in the OAI-PMH 2.0 standard itself.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Removed requirement for VOResource version number changes to force an update of this document.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Removed the entire section 2, specifically the SOAP-based services
based on "ADQL 1.0" and XQuery.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Dropped the requirement on registries to not deliver any records that are OAI-PMH deleted when no temporal constraint is given.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Announcing a migration to
<span class="nolinkurl">ivo://ivoa.net/std/Registry#OAI-2.0</span> as the harvesting
capability's standard id.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Added a requirement to provide VOSI endpoints.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Clarified that the requirement to keep deleted records for six
months only applies to the transient case; also discouraging registries
with no support of deleted records.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Added recommended process for discovery of registries and their resources using the Registry of Registries, based on the Registry of Registries IVOA note
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
<li> Many editorial changes across the text, mostly as a consequence of
externalizing the search interface.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
</li>
</ul>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<h2>References</h2>
<dl>
<a name="std:RI1"/>
<dt><b>Benson et al. (2009)</b></dt>
<dd>
Benson, K., Plante, R., Auden, E., Graham, M., Greene, G., Hill, M., Linde, T.,
Morris, D., O'Mullane, W., Rixon, G., Stébé, A. & Andrews, K.
(2009), `IVOA registry interfaces version
1.0', IVOA Recommendation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/RegistryInterface/"><tt>http://www.ivoa.net/documents/RegistryInterface/</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:RegTAP"/>
</dd>
<dt><b>Demleitner et al. (2013)</b></dt>
<dd>
Demleitner, M., Harrison, P., Molinaro, M., Greene, G., Dower, T. & Perdikeas, M. (2013), `IVOA registry
relational schema', IVOA Working Draft.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/RegTAP/"><tt>http://www.ivoa.net/documents/RegTAP/</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="paper:regclient"/>
</dd>
<dt><b>Demleitner et al. (2015)</b></dt>
<dd>
Demleitner, M., Harrison, P., Taylor, M. & Normand, J.
(2015), `Client interfaces to the Virtual
Observatory Registry', <em>Astronomy and Computing</em> <b>10</b>, 88-98,
arXiv:1502.01186.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:TAP"/>
</dd>
<dt><b>Dowler et al. (2010)</b></dt>
<dd>
Dowler, P., Rixon, G. & Tody, D. (
2010), `Table access protocol version 1.0', IVOA
Recommendation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/TAP"><tt>http://www.ivoa.net/documents/TAP</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:VOSI"/>
</dd>
<dt><b>Grid and Web Services Working Group (2011)</b></dt>
<dd>
Grid and Web Services Working Group (2011),
`IVOA support interfaces version 1.0'.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/VOSI/index.html"><tt>http://www.ivoa.net/documents/VOSI/index.html</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:RM"/>
</dd>
<dt><b>Hanisch et al. (2007)</b></dt>
<dd>
Hanisch, R., IVOA Resource Registry Working Group & NVO Metadata
Working Group (2007), `Resource metadata
for the virtual observatory', IVOA Recommendation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/latest/RM.html"><tt>http://www.ivoa.net/documents/latest/RM.html</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:OAIPMH"/>
</dd>
<dt><b>Lagoze et al. (2002)</b></dt>
<dd>
Lagoze, C., de Sompel, H. V., Nelson, M. & Warner, S.
(2002), `The open archives initiative
protocol for metadata harvesting, version 2.0'.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.openarchives.org/OAI/openarchivesprotocol.html"><tt>http://www.openarchives.org/OAI/openarchivesprotocol.html</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:VOR"/>
</dd>
<dt><b>Plante et al. (2008)</b></dt>
<dd>
Plante, R., Benson, K., Graham, M., Greene, G., Harrison, P., Lemson, G.,
Linde, T., Rixon, G. & Stébé, A. (
2008), `VOResource: an XML encoding schema for resource
metadata version 1.03', IVOA Recommendation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/REC/ReR/VOResource-20080222.html"><tt>http://www.ivoa.net/documents/REC/ReR/VOResource-20080222.html</tt></a>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="2004ASPC..314..585P"/>
</dd>
<dt><b>Plante et al. (2004)</b></dt>
<dd>
Plante, R., Greene, G., Hanisch, R., McGlynn, T., O'Mullane, W.
& Williamson, R. (2004),
Resource Registries for the Virtual Observatory, <em>in</em> F. Ochsenbein,
M. G. Allen & D. Egret, eds, `Astronomical Data Analysis
Software and Systems (ADASS) XIII', Vol. 314 of <em>Astronomical Society of
the Pacific Conference Series</em>, p. 585.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a name="std:VOID"/>
</dd>
<dt><b>Plante et al. (2007)</b></dt>
<dd>
Plante, R., Linde, T., Williams, R. & Noddle, K. (
2007), `IVOA identifiers, version 1.03', IVOA
Recommendation.
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a href="http://www.ivoa.net/documents/REC/Identifiers/Identifiers-20070302.html"><tt>http://www.ivoa.net/documents/REC/Identifiers/Identifiers-20070302.html</tt></a></dd>
</dl>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<hr/><h3>Footnotes:</h3>
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span/></p>
<a id="tthFtNtAAB"/><a href="#tthFrefAAB"><sup>1</sup></a>For instance, RegTAP
<a href="#std:RegTAP" class="tth_citeref">
(Demleitner et al., 2013)</a> uses
the <span class="xmlel">tre:dataModel</span> element from TAPRegExt as its primary
discovery mechanism
<br/><br/><hr/><small>File translated from
T<sub><span class="small">E</span></sub>X
by <a href="http://hutchinson.belmont.ma.us/tth/">
T<sub><span class="small">T</span></sub>H</a>,
version 4.08.<br/>On 09 May 2016, 05:49.</small>
</div></html>