OAICoordination < IVOA

IVOA Web>IvoaResReg>IVOARegWp05>OAICoordination (2003-12-18, RayPlante) (raw view)
*Links:*  IvoaResReg :: [[http://www.ivoa.net/forum/registry/][registry mail archive]] :: IVOARegWp03 :: IVOARegWp04

---+ OAI Coordination

OAI stands for the [[http://www.openarchives.org][Open Archives Initiative]] an effort from within the digital library community to develop open standards for archive interoperability.  However, the abbreviation is often used to refer specifically to the [[http://www.openarchives.org/OAI/openarchivesprotocol.html][OAI Protocol for Metadata Harvesting (OAI-PMH)]].  
This page describes issues we need to address to ensure uniformity across our OAI interfaces.


__Contents__
%TOC%

---++ 1. Things we need to agree on to make our OAI interfaces look the same:

---+++ 1.1.  Metadata format name for VOResource metadata: ivo_vor

This name is used in two places:
   * It is returned as one of the supported formats in the response to the [[http://www.openarchives.org/OAI/openarchivesprotocol.html#ListMetadataFormats][ListMetadataFormats]] query, refering to the VOResource schema.  The format description should look like this:

<pre><font size="-1">&lt;metadataFormat&gt;
  &lt;metadataPrefix&gt;ivo_vor&lt;/metadataPrefix&gt;
  &lt;schema&gt;http://www.ivoa.net/xml/VOResource/VOResource-v0.9.xsd&lt;/schema&gt;
  &lt;metadataNamespace&gt;http://www.ivoa.net/xml/VOResource/v0.9&lt;/metadataNamespace&gt;
&lt;/metadataFormat&gt;</font></pre>

   * It can be used as a value for the ==metadataPrefix== argument to the [[http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord][GetRecord]] and [[http://www.openarchives.org/OAI/openarchivesprotocol.html#ListRecords][ListRecords]]  queries.  It also appears in the responses to these in the value of the ==metadataPrefix== attribute to the ==request== element.

ivo_vor was Sebastien's suggestion and we got sufficient agreement.  It doesn't matter too much what we use, as long as we use the same name.  

---+++ 1.2.  The "root" element for the VOResource metadata should be ==&lt;VOResource&gt;==.

<pre><font size="=1">&lt;OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
         http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"&gt;
  &lt;responseDate&gt;2004-01-05T19:20:30Z&lt;/responseDate&gt; 
  &lt;request verb="ListRecords" from="2004-01-01"
           metadataPrefix="ivo_vor"&gt;...&lt;/request&gt;
  &lt;ListRecords&gt;
    &lt;record&gt;
      &lt;header&gt;
        &lt;identifier&gt;...&lt;/identifier&gt;
        &lt;datestamp&gt;...&lt;/datestamp&gt;
      &lt;/header&gt;
      &lt;metadata&gt;
         <font color="red">&lt;VOResource xmlns="http://www.ivoa.net/xml/VOResource/v0.9"&gt;
            ...
         &lt;/VOResource&gt;</font>
      &lt;/metadata&gt;
    &lt;/record&gt;
    ...
  &lt;/ListRecords&gt;
&lt;/OAI-PMH&gt;</font></pre>

This is better than using ==VODescription== because ==VOResource== guarantees (via the schema) that only 1 resource is being described, making this requirement verifiable by any XML verifier (including the [[http://oai.dlib.vt.edu/cgi-bin/Explorer/oai2.0/testoai][OAI Explorer]].  

It's also better than using ==Resource== or one of its sub-classes (e.g. ==Organisation==, ==Service==, etc.), as this complicated the handling of the metadata on the harvester's end when several possible elements are allowed at this level.

This may not be a big deal in the short term, but in the long-term 
it will make it easier for a harvester to decide if it can handle 
the record.  In general, any application must answer the 
following questions:
   *  is the XML instance valid (for the schemas I know/care about)?
   *  is the root element what I need/expect it to be?

The second question is easier to answer if there is only one 
possible root element to check for.

---+++ 1.3 The form of the OAI identifier; i.e. the value of &lt;oai:identifier&gt;. <font color="red">Deferred until after Jan!</font>

I would like to see us use our IVOA identifiers (in their URI forms) 
here.  Otherwise, we will find ourselves having to keep track of two 
identifiers.  

This might seem like a no-brainer, but several of us (including us at 
NCSA!) are using the OAI interface script from Virginia Tech, which 
creates its own OAI identifiers based on the local XML file name.  

Ramon has placed a modified version of this script at 
[[http://nvo.ncsa.uiuc.edu/VO/software/XMLFileDP_vo.pm]] that is meant to 
serve as a drop in replacement for <nop>XMLFileDP.pm.  (Replace your old 
<nop>XMLFileDP.pm in the perl library directory used by your oai.pl script.)  
This version will override the default OAI identifiers with the IVOA 
ones found in the corresponding VOResource files.  It also has the 
added benefit of supporting deleted records.

<font color="red">
Several people have suggested we defer unifying on this item until after January, since it is not absolutely critical.  This only becomes a practical issue when a harvester uses the [[http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord][GetRecord]] function.  As far as I know, none of our harvest<em>ing</em> registries do.
</font>

---+++ 1.4  Each OAI interface must export one ==&lt;Authority&gt;== record for each <nop>AuthorityID it controls.

(See [[http://nvo.ncsa.uiuc.edu/VO/schemas/vomdoc-v0.9/VORegistry-v0.2.html#element_Authority][Authority Resource Definition]].)  By "control", we mean that it creates resource descriptions for.  These records are used to trace back where a resource record originates from.   

---+++ 1.5  Each OAI interface must export one ==&lt;Registry&gt;== record describing itself.

(See [[http://nvo.ncsa.uiuc.edu/VO/schemas/vomdoc-v0.9/VORegistry-v0.2.html#element_Registry][Registry Resource Definition]].)  This record should include a listing of all <nop>AuthorityIDs it manages (i.e. that it has ==&lt;Authority&gt;== records for) using the ==&lt;ManagedAuthority&gt;== element.  These records are used to trace back where a resource record originates from.   


---+++ 1.6.  Standard Services (<nop>ConeSearch, SIA) should include the appropriate ==Capability== sub-element.

By standard service, we mean a service that has a schema extension associated with it.  Current examples are <nop>ConeSearch and SIA.  Each extension schema defines an element (==&lt;ConeSearch&gt;== and ==&lt;SimpleImageAccess&gt;==, respectively) that inherits from ==&lt;Capability&gt;== which contains service-type-specific metadata.  

All records that describe one of these standard services should included either the ==&lt;ConeSearch&gt;== or ==&lt;SimpleImageAccess&gt;== tag, even if that tag contains no content.  Currently, the [[http://heasarc.gsfc.nasa.gov/vo/data-inventory.html][Data Inventory Service]] looks for this tag to determine what type of service it is.

---+++ 1.7.  Set ==ContentLevel== to "Research" if you want it chosen by the [[http://heasarc.gsfc.nasa.gov/vo/data-inventory.html][DIS]]

By convention, the [[http://heasarc.gsfc.nasa.gov/vo/data-inventory.html][Data Inventory Service (DIS)]] request from the registry only those services with the [[http://nvo.ncsa.uiuc.edu/VO/schemas/vomdoc-v0.9/VOResource-v0.9.html#element_ContentLevel][&lt;ContentLevel&gt;]] element set to "Research".  Some data providers have used this convention to prevent the DIS from using certain services (because, say, their are not fully operational) by _not_ setting ==ContentLevel== to "Research".



-- IVOA.RayPlante - 18 Dec 2003




<br><br><br>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r3 - 2003-12-18 - RayPlante
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema