[Volute] r3635 - trunk/projects/registry/RegistryInterface

Volute commit messages volutecommits at g-vo.org
Tue Oct 18 14:30:48 CEST 2016


Author: dower
Date: Tue Oct 18 14:30:48 2016
New Revision: 3635

Log:
RegistryInterface: removed duplicate vg:Harvest example.
Expanded date format in harvest example for consistency.
Incorporated mdemleitner's rule changes for finding RegTAP interfaces

Modified:
   trunk/projects/registry/RegistryInterface/RegistryInterface.tex

Modified: trunk/projects/registry/RegistryInterface/RegistryInterface.tex
==============================================================================
--- trunk/projects/registry/RegistryInterface/RegistryInterface.tex	Tue Oct 18 14:05:27 2016	(r3634)
+++ trunk/projects/registry/RegistryInterface/RegistryInterface.tex	Tue Oct 18 14:30:48 2016	(r3635)
@@ -633,12 +633,12 @@
 When a registry creates a
 \xmlel{vg:Authority} 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 \xmlel{vg:managedAuthority} element to the registry's
-own resource record.
+because only that registry may create records with identifiers beginning
+with that authority identifier. The registry must also document this ownership
+by adding a corresponding \xmlel{vg:managedAuthority} element to the 
+registry's own resource record.
 
-The mechanism outlined here is not race-free in the distributed
+The mechanism outlined here is not free of conflicts 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.
@@ -647,47 +647,6 @@
 
 \label{sect:resext}
 
-
-\begin{figure}[thm]
-\begin{lstlisting}[language=XML]
-<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="2.0" role="std">
-      <accessURL>http://rofr.ivoa.net/oai</accessURL>
-    </interface>
-    <maxRecords>0</maxRecords>
-  </capability>
-
-  <full>false</full>
-
-  <managedAuthority>ivoa.net</managedAuthority>
-</ri:Resource>
-\end{lstlisting}
-\caption{A sample \xmlel{vg:Registry}-typed resource record as it would
-be delivered within \xmlel{oai:metadata}, including a harvest capability.  
-XML namespace declarations
-are for the prefixes \xmlel{ri:}, \xmlel{xsi:}, and \xmlel{vg:} are
-assumed on enclosing elements.}
-\label{fig:regrecord}
-\end{figure}
-
-
 The \xmlel{vg:Registry} type extends the core \xmlel{vr:Service} type to
 specifically describe registries in order to support discovering them
 and collecting their metadata; in addition, the extension type also
@@ -709,8 +668,8 @@
 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 \xmlel{vg:Harvest} capability), too.
+interface, but there are also use cases for full registries only
+implementing OAI-PMH (and thus only providing an \xmlel{vg:Harvest} capability).
 
 The \xmlel{vg:managedAuthority} is used by publishing registries  to
 claim an authority identifier (see also sect.~\ref{oairequired}).  Note
@@ -746,7 +705,8 @@
 
 A registry declares itself to be a harvestable registry by including a
 \xmlel{vr:capability} element with an \xmlel{xsi:type} 
-attribute set to \xmlel{vg:Harvest}.
+attribute set to \xmlel{vg:Harvest}. An example capability for this
+type is provided in the appendix \ref{sect:exampleCap}.
 
 A \xmlel{vr:capability} element of type \xmlel{vg:Harvest} MUST
 include at least one \xmlel{vr:interface} element with an
@@ -856,9 +816,9 @@
 called as such:
 \nolinkurl{http://accessURLValue?verb=ListRecords\&metadataPrefix=ivo\_vor}
 or
-\nolinkurl{http://accessURLValue?verb=ListRecords\&metadataPrefix=ivo_vor\&from=YYYY-MM-DD}
-for return visits, with YYYY-MM-DD representing the last successful
-query to that accessURL.
+\nolinkurl{http://accessURLValue?verb=ListRecords\&metadataPrefix=ivo_vor\&from=YYYY-MM-DDTHH:MM:SSZ}
+for return visits, with the 'from' date representing the last successful
+query to that accessURL. Note according to the OAI-PMH standard the granularity of dates in 'from' fields is optional beyond day (DD), and some overlap in requested timeframes may be useful from an operational standpoint.
 
 \section{Searching the Registry}
 
@@ -884,12 +844,17 @@
 Also, the type may be useful when other registry search interfaces want
 to define capability types of their own.
 
-RegTAP service capabilities and other additional search capabilities
-other than the deprecated but allowed RISearch are to be included in the
-registry self-identification record as an auxiliary capability as
-described in the IVOA note "Discovering Data Collections Within
-Services" \citep{note:DataCollect}, with the main capability being the
-OAI-PMH harvester service endpoint.
+RegTAP-based registries should be located by clients as described 
+in the RegTAP standard (which in version 1.0 happens through locating 
+TAP services with a certain data model identifier like 
+\nolinkurl{ivo://ivoa.net/std/RegTAP#1.0}).  To aid the Registry of 
+Registries in generating lists for initial discovery, RegTAP registries 
+must also be registered as separate resources with the appropriate tableset.  
+These must include either a full TAP service capability according to
+TAPRegExt \citep{2012ivoa.spec.0827D} or an auxiliary capability
+referencing a TAP service as per \citep{note:DataCollect}.  An example
+for the latter option, preferable if the TAP service in question
+contains additional tables, is given in appendix \ref{sect:exampleCap}.
 
 The concept of a searchable registry versus a publishing one as
 recognized by the Registry of Registries therefore now encompasses any
@@ -928,6 +893,7 @@
 \lstinputlisting[language=XML]{VORegistry-1.0.xsd}
 
 \section{Example Capabilities}
+\label{sect:exampleCap}
 
 The following XML fragment shows the three capability elements discussed
 in this document: The OAI-PMH-based publishing registry, the legacy 


More information about the Volutecommits mailing list