Implementation Guidelines for the Open Archives Initiative Protocol for Metadata Harvesting

OAI logo

Specification for an OAI Static Repository and an OAI Static Repository Gateway

  Protocol Version 2.0 of 2002-06-14
Document Version 2004/04/23T15:17:00Z
http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm

Editors

The OAI Executive:
Herbert Van de Sompel <herbertv@lanl.gov> -- Los Alamos National Laboratory - Research Library
Carl Lagoze <lagoze@cs.cornell.edu> -- Cornell University - Computing and Information Science

From the OAI Technical Committee:
Michael Nelson <mln@cs.odu.edu> -- Old Dominion University - Dept of Computer Science
Simeon Warner <simeon@cs.cornell.edu> -- Cornell University - Computing and Information Science

Contributors:
Patrick Hochstenbach <hochsten@lanl.gov> -- Los Alamos National Laboratory - Research Library
Henry Jerez <hjerez@lanl.gov> -- Los Alamos National Laboratory - Research Library

This document is one part of the Implementation Guidelines that accompany the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH).

Table of Contents

1. Introduction
2. Concepts and Definitions
3. Static Repository Description
   3.1 Static Repository Overview
   3.2 Static Repository Conformance Rules
   3.3 Initiating Intermediation with a Static Repository Gateway
   3.4 Terminating Intermediation by a Static Repository Gateway
   3.5 Ongoing Access to a Static Repository
   3.6 Static Repository Example
4. Static Repository Gateway Description
   4.1 Initiating Intermediation for Static Repositories
   4.2 Terminating Intermediation for Static Repositories
      4.2.1 Terminating Intermediation by Request
      4.2.2 Terminating Intermediation Unilaterally
   4.3 Providing Intermediation for Static Repositories
   4.4 Additional OAI-PMH Issues for Static Repository Gateways
      4.4.1 Contents of the OAI-PMH Identify Response Provided by a Static Repository Gateway
      4.4.2 Static Repository Gateway Flow Control
   4.5 Security Considerations
A1. XML Schema
   A1.1 Static Repository XML Schema
   A1.2 Restricted OAI-PMH XML Schema
Acknowledgements
Document History

1. Introduction

Knowledge of the OAI-PMH is a prerequisite for understanding this document.

A Static Repository, introduced here, provides a simple approach for exposing relatively static and small collections of metadata records through the OAI-PMH. The Static Repository approach is targeted at organizations that:

A Static Repository is an XML file that is made accessible at a persistent HTTP URL. The XML file contains metadata records and repository information.

A Static Repository becomes accessible via OAI-PMH through the intermediation of one Static Repository Gateway. The restriction that only one Static Repository Gateway acts as an intermediary for each Static Repository reduces potential problems with large-scale duplication of metadata records among OAI-PMH repositories. A Static Repository Gateway uses the metadata records and repository information, provided via XML in the Static Repository, to respond to the six OAI-PMH requests for access to that information. Because a Static Repository Gateway maps a unique Static Repository base URL to each such Static Repository, harvesters can access a Static Repository in exactly the same manner as they access any other OAI-PMH Repository.

The relationship between Static Repositories, a Static Repository Gateway, and an OAI-PMH harvester is illustrated in the figure below. The Static Repository and the Static Repository Gateway are described in the remainder of this document. Implementers whose sole interest is the creation of a Static Repository may skip Section 4 that describes the Static Repository Gateway.

Static Repositories, a Static Repository Gateway and an OAI-PMH Harvester
Repository-gateway relationship figure

2. Concepts and Definitions

Some concepts that are essential for an understanding of this specification are given below.

Static Repository: A Static Repository is an XML file, available at a persistent HTTP URL that conforms to the rules in Section 3.2. A Static Repository contains metadata records and supporting information required for the purpose of harvesting via the OAI-PMH through the intermediation of a Static Repository Gateway. A Static Repository is not a OAI-PMH Repository, because it is a file, not a server that can respond to the six OAI-PMH requests.

Static Repository URL: The HTTP URL where the Static Repository is accessible.

Static Repository Gateway: A Static Repository Gateway provides intermediation for one or more Static Repositories. It assigns each such Static Repository a unique Static Repository base URL, all with a common Static Repository Gateway URL prefix, and thereby exposes each individual Static Repository as an individual OAI-PMH Repository.

Static Repository Gateway URL: The HTTP URL of the Static Repository Gateway that provides the common prefix for all base URLs of Static Repositories for which the Static Repository Gateway provides intermediation.

Intermediation: The relationship between a Static Repository Gateway and one or more Static Repositories, whereby the Static Repository Gateway responds to OAI-PMH requests to provide access to those Static Repositories. This intermediation is opaque to harvesters, who send OAI-PMH requests to the Static Repository base URL associated with the target Static Repository, even though those requests are actually processed by the Static Repository Gateway.

Static Repository base URL: The base URL that provides access via OAI-PMH to the contents of the Static Repository through intermediation by a Static Repository Gateway. This Static Repository base URL is a concatenation of:

For example, OAI-PMH requests to a Static Repository at http://an.oai.org/ma/mini.xml using intermediation from a Static Repository Gateway at http://gateway.institution.org/oai must be issued against the Static Repository base URL:

    http://gateway.institution.org/oai/an.oai.org/ma/mini.xml

3. Static Repository Description

3.1 Static Repository Overview

Static Repositories are useful for small and relatively static metadata collections. All metadata, identifiers, and datestamps are managed in a single XML file that must conform to the rules in Section 3.2. This file may be created manually with an XML editing tool, or a text processing application. Alternatively, a Static Repository might be generated periodically by a script that extracts information from an existing database.

A Static Repository must only be accessible at a single Static Repository URL. This must be an HTTP URL of the form:

    http://host:port/path/file

The HTTP URL must not contain a fragment or a query string. The contents of the Static Repository provide metadata records and repository information necessary for intermediation by a Static Repository Gateway. There are a number of restrictions on a Static Repository relative to a standard OAI-PMH Repository. Static Repositories do not support sets, deleted records, response compression, harvesting granularity other than YYYY-MM-DD, or resumptionTokens.

3.2 Static Repository Conformance Rules

A Static Repository must comply with the following conformance rules:

It is strongly recommended that the identifiers of metadata records in the Static Repository conform to the guidelines for OAI identifiers or other forms of Uniform Resource Names (URNs) in the sense of RFC1737. This practice will facilitate the ability to recognize duplicates among harvested metadata records.

3.3 Initiating Intermediation with a Static Repository Gateway

OAI-PMH access to a Static Repository is only possible through the intermediation of a Static Repository Gateway. To initiate this intermediation, the administrator of a Static Repository must select one Static Repository Gateway that will act as the intermediary and must issue an HTTP GET request of the form:

    <Static Repository Gateway URL>?initiate=<Static Repository URL>

For example, an administrator of a Static Repository with a Static Repository URL of http://an.oai.org/ma/mini.xml requesting intermediation from a Static Repository Gateway with a Static Repository Gateway URL http://gateway.institution.org/oai must issue the HTTP GET request:

    http://gateway.institution.org/oai?initiate=http://an.oai.org/ma/mini.xml

The policies and implementation of the Static Repository Gateway will determine both whether any additional steps are necessary, and the length of any delay between issuance of this request and the actual initiation of intermediation. For example, a particular Static Repository Gateway may have a policy that requires gateway administrator intervention and email exchange before initiating intermediation. The Static Repository Gateway administrator should follow the instructions concerning ongoing access to a Static Repository to check that intermediation is successful.

3.4 Terminating Intermediation by a Static Repository Gateway

To terminate intermediation by a Static Repository Gateway, the administrator of a Static Repository must first either remove the Static Repository from its Static Repository URL, or change the baseURL element so that it no longer matches the Static Repository base URL. The administrator must then issue an HTTP GET request of the form:

    <Static Repository Gateway URL>?terminate=<Static Repository URL>

For example, an administrator of a Static Repository with a Static Repository URL of http://an.oai.org/ma/mini.xml requesting the termination of intermediation from a Static Repository Gateway with a Static Repository Gateway URL http://gateway.institution.org/oai must issue the HTTP GET request:

    http://gateway.institution.org/oai?terminate=http://an.oai.org/ma/mini.xml

The Static Repository Gateway will respond to a termination request according to the following rules.

The policies and implementation of the Static Repository Gateway will determine both whether any additional steps are necessary, and the length of any delay between issuance of this request and the actual termination of intermediation. The Static Repository Gateway administrator should follow the instructions concerning ongoing access to a Static Repository to check whether the attempt to terminate intermediation is successful.

3.5 Ongoing Access to a Static Repository

An administrator of a Static Repository should be aware that access to the Static Repository is dependent on the intermediation of a single Static Repository Gateway. The Static Repository conformance rules prohibit intermediation by more than one Static Repository Gateway by demanding a match between the baseURL element in the Static Repository and the Static Repository base URL at which it is available through the intermediation of the Static Repository Gateway.

It is recommended that the administrator check that intermediation is successful by issuing an OAI-PMH Identify request to the appropriate Static Repository base URL:

The response to this Identify request will be one of the following:

3.6 Static Repository Example

Below, an example is shown of a Static Repository. As can be seen, it contains:

Static Repository Example
<?xml version="1.0" encoding="UTF-8"?>
<Repository xmlns="http://www.openarchives.org/OAI/2.0/static-repository" 
            xmlns:oai="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/static-repository 
                                http://www.openarchives.org/OAI/2.0/static-repository.xsd">
  <Identify>
    <oai:repositoryName>Demo repository</oai:repositoryName>
    <oai:baseURL>http://gateway.institution.org/oai/an.oai.org/ma/mini.xml</oai:baseURL>
    <oai:protocolVersion>2.0</oai:protocolVersion>
    <oai:adminEmail>jondoe@oai.org</oai:adminEmail>
    <oai:earliestDatestamp>2002-09-19</oai:earliestDatestamp>
    <oai:deletedRecord>no</oai:deletedRecord>
    <oai:granularity>YYYY-MM-DD</oai:granularity>
  </Identify>
  <ListMetadataFormats>
    <oai:metadataFormat>
      <oai:metadataPrefix>oai_dc</oai:metadataPrefix>
      <oai:schema>http://www.openarchives.org/OAI/2.0/oai_dc.xsd</oai:schema>
      <oai:metadataNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</oai:metadataNamespace>
    </oai:metadataFormat>
    <oai:metadataFormat>
      <oai:metadataPrefix>oai_rfc1807</oai:metadataPrefix>
      <oai:schema>http://www.openarchives.org/OAI/1.1/rfc1807.xsd</oai:schema>
      <oai:metadataNamespace>http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1807.txt</oai:metadataNamespace>
    </oai:metadataFormat>
  </ListMetadataFormats>
  <ListRecords metadataPrefix="oai_dc">
    <oai:record> 
      <oai:header>
        <oai:identifier>oai:arXiv:cs/0112017</oai:identifier> 
        <oai:datestamp>2001-12-14</oai:datestamp>
      </oai:header>
      <oai:metadata>
        <oai_dc:dc 
            xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" 
            xmlns:dc="http://purl.org/dc/elements/1.1/" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ 
                                http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:title>Using Structural Metadata to Localize Experience of 
                    Digital Content</dc:title> 
          <dc:creator>Dushay, Naomi</dc:creator>
          <dc:subject>Digital Libraries</dc:subject> 
          <dc:description>With the increasing technical sophistication of 
            both information consumers and providers, there is 
            increasing demand for more meaningful experiences of digital 
            information. We present a framework that separates digital 
            object experience, or rendering, from digital object storage 
            and manipulation, so the rendering can be tailored to 
            particular communities of users.
          </dc:description> 
          <dc:description>Comment: 23 pages including 2 appendices, 
            8 figures</dc:description> 
          <dc:date>2001-12-14</dc:date>
        </oai_dc:dc>
      </oai:metadata>
    </oai:record>  
    <oai:record>
      <oai:header>
        <oai:identifier>oai:perseus:Perseus:text:1999.02.0084</oai:identifier>
        <oai:datestamp>2002-05-01</oai:datestamp>
      </oai:header>
      <oai:metadata>
        <oai_dc:dc 
            xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" 
            xmlns:dc="http://purl.org/dc/elements/1.1/" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ 
                                http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:title>Germany and its Tribes</dc:title>
          <dc:creator>Tacitus</dc:creator>
          <dc:type>text</dc:type>
          <dc:source>Complete Works of Tacitus. Tacitus. Alfred John Church. 
            William Jackson Brodribb. Lisa Cerrato. edited for Perseus. 
            New York: Random House, Inc. Random House, Inc. reprinted 1942.
          </dc:source>
          <dc:identifier>http://www.perseus.tufts.edu/cgi-bin/ptext?
            doc=Perseus:text:1999.02.0083</dc:identifier>
        </oai_dc:dc>
      </oai:metadata>
    </oai:record>
  </ListRecords>
  <ListRecords metadataPrefix="oai_rfc1807">
    <oai:record>
      <oai:header>
        <oai:identifier>oai:arXiv:cs/0112017</oai:identifier>
        <oai:datestamp>2001-12-14</oai:datestamp>
      </oai:header>
      <oai:metadata>
        <rfc1807 
            xmlns="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1807.txt" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xsi:schemaLocation="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1807.txt
                                http://www.openarchives.org/OAI/1.1/rfc1807.xsd">
          <bib-version>v2</bib-version>
          <id>cs/0112017</id>
          <entry>December 23, 2001</entry>
          <title>Using Structural Metadata to Localize Experience of 
             Digital Content</title>
          <author>Naomi Dushay</author>
          <date>December 14, 2001</date>
        </rfc1807>
      </oai:metadata>
      <oai:about>
        <oai_dc:dc 
            xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" 
            xmlns:dc="http://purl.org/dc/elements/1.1/" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ 
                                http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:publisher>Los Alamos arXiv</dc:publisher>
          <dc:rights>Metadata may be used without restrictions as long as 
            the oai identifier remains attached to it.</dc:rights>
        </oai_dc:dc>
      </oai:about>
    </oai:record>
  </ListRecords>
</Repository>

4. Static Repository Gateway Description

NOTE: Implementers whose sole interest is the creation of a Static Repository may skip this section.

A Static Repository Gateway provides intermediation for one or more Static Repositories. The OAI-PMH base URL for each Static Repository is unique, but all Static Repositories intermediated by one Static Repository Gateway share a common prefix, the Static Repository Gateway URL. To discourage excessive duplication of metadata records, a Static Repository Gateway must not process OAI-PMH requests for a Static Repository if the Static Repository base URL of the request does not match the value of the baseURL element of the Static Repository. A Static Repository Gateway must not change the metadata expressed in the Static Repository. Downstream services may alter, augment or cross-walk the metadata but the sole purpose of a Static Repository Gateway is to intermediate access to the Static Repository.

The implementation of a Static Repository Gateway has three aspects:

  1. Initiating intermediation for Static Repositories.
  2. Providing intermediation for Static Repositories
  3. Terminating intermediation for Static Repositories

4.1 Initiating Intermediation for Static Repositories

Section 3.3 of this document describes how an administrator of a Static Repository initiates intermediation with a single Static Repository Gateway. This section provides information about this relationship from the perspective of the Static Repository Gateway.

A Static Repository Gateway must process HTTP GET requests of the form:

    <Static Repository Gateway URL>?initiate=<Static Repository URL>

A Static Repository Gateway may implement any local policies or procedures subsequent to receiving this request and before actually acting as an intermediary. These may include additional authorization or certification procedures outside the scope of the OAI-PMH.

4.2 Terminating Intermediation for Static Repositories

Intermediation for a Static Repository may be terminated either following a request from the administrator of the Static Repository, or unilaterally by the Static Repository Gateway.

4.2.1 Terminating Intermediation by Request

Section 3.4 of this document describes how an administrator of a Static Repository terminates intermediation with a single Static Repository Gateway. This section provides information about this relationship from the perspective of the Static Repository Gateway.

A Static Repository Gateway must process HTTP GET requests of the form:

    <Static Repository Gateway URL>?terminate=<Static Repository URL>

On receipt of such a request, the Static Repository Gateway must attempt to fetch the Static Repository and follow these rules:

It is recommended that an email message to the Static Repository administrator (address available in the adminEmail element of the Static Repository) be sent regarding the termination.

4.2.2 Terminating Intermediation Unilaterally

A Static Repository Gateway may unilaterally terminate an intermediation relationship at any time. Some of the possible reasons for this termination are:

It is recommended that an email message to the Static Repository administrator (address available in the adminEmail element of the Static Repository) be sent regarding the termination.

4.3 Providing Intermediation for Static Repositories

Once a Static Repository Gateway has accepted intermediation for a Static Repository, it must respond to all six OAI-PMH requests issued against the Static Repository base URL, for the length of the intermediation relationship.

In order to guarantee the accuracy of the exposed metadata, a Static Repository Gateway must use the most recent version of a Static Repository. A Static Repository Gateway may accomplish this by fetching the Static Repository from its persistent Static Repository URL using an HTTP GET request for every OAI-PMH request received. However, a Static Repository Gateway may optimize its performance by caching Static Repositories. In that case a Static Repository Gateway must perform a freshness-test on the cached Static Repository by comparing it with the version at the Static Repository URL before responding to every OAI-PMH request. It should do so by using a HTTP GET with an If-Modified-Since header that contains the date of the cached version of a Static Repository.

The response of a Static Repository Gateway to an OAI-PMH request issued against the Static Repository base URL must take one of the following forms:

4.4 Additional OAI-PMH Issues for Static Repository Gateways

OAI-PMH processing by a Static Repository Gateway is mandated by the OAI-PMH specification. This section describes a number of special issues relevant to this specification.

4.4.1 Contents of the OAI-PMH Identify Response Provided by a Static Repository Gateway

A Static Repository Gateway must add a gateway description to the Identify response for each Static Repository for which it provides intermediation. The gateway description reveals that the OAI-PMH response is provided through the intermediation of a Static Repository Gateway. The gateway description must include the following elements:

The gateway description may also include:

To support dynamic discovery of Static Repositories, the Static Repository Gateway may include a friends description in the Identify response that it provides for each of the Static Repositories for which it provides intermediation. If included, that friends description should list the base URLs of all Static Repositories that are harvestable through the Static Repository Gateway. A Static Repository Gateway may develop a policy to periodically refresh the friends description, for instance based on tracking the (un)availability of listed Static Repositories over time.

An example of a response to the Identify request from a Static Repository Gateway with Static Repository Gateway URL http://gateway.institution.org/oai issued against the example Static Repository (section 3.6), is shown below:

Response to an Identify request issued against a Static Repository
<?xml version="1.0" encoding="UTF-8"?>
<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">
  <responseDate>2002-02-08T12:00:01Z</responseDate>
  <request verb="Identify">http://gateway.institution.org/oai/an.oai.org/ma/mini.xml</request>
  <Identify>
    <repositoryName>Demo repository</repositoryName>
    <baseURL>http://gateway.institution.org/oai/an.oai.org/ma/mini.xml</baseURL>
    <protocolVersion>2.0</protocolVersion>
    <adminEmail>jondoe@oai.org</adminEmail>
    <earliestDatestamp>2002-09-19</earliestDatestamp>
    <deletedRecord>no</deletedRecord>
    <granularity>YYYY-MM-DD</granularity>
    <description>
      <friends 
          xmlns="http://www.openarchives.org/OAI/2.0/friends/" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/friends/
                              http://www.openarchives.org/OAI/2.0/friends.xsd">
        <baseURL>http://gateway.institution.org/oai/site1.org/mini/file1</baseURL>
        <baseURL>http://gateway.institution.org/oai/loca.org%3A8080/data</baseURL>
        <baseURL>http://gateway.institution.org/oai/univ.edu/lib/pubs.xml</baseURL>
      </friends>
    </description>
    <description>
      <gateway 
          xmlns="http://www.openarchives.org/OAI/2.0/gateway/" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/gateway/
                              http://www.openarchives.org/OAI/2.0/gateway.xsd">
        <source>http://an.oai.org/ma/mini.xml</source>
        <gatewayDescription>http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm</gatewayDescription>
        <gatewayAdmin>pat@institution.org</gatewayAdmin>
        <gatewayURL>http://gateway.institution.org/oai/</gatewayURL>
      </gateway>
    </description>
  </Identify>
</OAI-PMH>

4.4.2 Static Repository Gateway Flow Control

Like any OAI-PMH Repository, a Static Repository Gateway may use resumptionTokens as a means of partitioning large responses. However, the Static Repository must ensure that the Static Repository has not changed before responding to harvesting requests with a resumptionToken. In other words the entire set of requests in a list request sequence must be based on the same Static Repository contents. To do this, the Static Repository Gateway must perform a freshness-test on each request in the list request sequence. The Static Repository Gateway should do so by using a HTTP GET with an If-Modified-Since header that contains the date of the first request in the list request sequence of a Static Repository. If the result of the freshness-test is that the Static Repository has changed in the course of a list request sequence, the Static Repository Gateway must issue an OAI-PMH error badResumptionToken.

4.5 Security Considerations

The following security issues require attention when operating a Static Repository Gateway:

A1. XML Schema

Static repositories must validate against the Static Repository XML Schema. This schema imports elements from the OAI-PMH v2.0 namespace via an intermediate Restricted OAI-PMH XML Schema which enforces a number of the Static Repository Conformance Rules by restricting OAI-PMH v2.0 type definitions.

A1.1 Static Repository XML Schema

Static Repository XML Schema
<?xml version="1.0" encoding="utf-8"?>
<schema targetNamespace="http://www.openarchives.org/OAI/2.0/static-repository"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:sr="http://www.openarchives.org/OAI/2.0/static-repository"
        xmlns:oai="http://www.openarchives.org/OAI/2.0/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

  <import namespace="http://www.openarchives.org/OAI/2.0/"
          schemaLocation="http://www.openarchives.org/OAI/2.0/OAI-PMH-static-repository.xsd"/>

  <annotation>
    <documentation>
    This XML Schema specifies the structure of an OAI-PMH Static Repository. 
    A Static Repository is an XML file that is valid according to this XML 
    Schema and is described in 
    http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm
    A Static Repository is made accessible as an XML file on a standard 
    web-server. No special software is required at the end of the organization
    that makes the Static Repository available. A Static Repository becomes 
    harvestable via the OAI-PMH through the intermediation of a Static 
    Repository Gateway. 

    This Static Repository XML Schema by Herbert Van de Sompel and Henry N. 
    Jerez (Los Alamos National Laboratory, Research Library, Digital Library 
    Research and Prototyping Team; original 2002-10-26), and Simeon Warner 
    (Cornell University). Inspired by the Vida work by Steven Bird for OAI-PMH
    v1.0 and for the Open Languages Archives Community; see 
    http://www.language-archives.org/docs/implement.html#Vida
    
    Beta2 release: 2004-03-30
    Release: 2004-04-23
    $Date: 2004/04/23 15:17:46 $
    </documentation>
  </annotation>

  <element name="Repository" type="sr:RepositoryType"/>

  <complexType name="RepositoryType">
    <annotation>
      <documentation>The Repository element has 2 child elements, Identify 
      and ListMetadataFormats, that are derived from the OAI-PMH v2.0 XML 
      Schema. The third element, ListRecords, is repeatable and is an 
      extension of the ListRecords defined in the OAI-PMH v2.0 XML Schema; 
      it has an additional attribute indicating the metadataPrefix of the 
      included metadata records.
      </documentation>
    </annotation>
    <sequence>
      <element name="Identify" type="oai:IdentifyType"/>
      <element name="ListMetadataFormats" type="oai:ListMetadataFormatsType"/>
      <element name="ListRecords" type="sr:ListRecordsType" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="ListRecordsType">
    <annotation>
      <documentation>The ListRecords element contains all records with 
      metadata expressed in one of the metadata formats supported by the 
      Static Repository. The mandatory metadataPrefix attribute specifies the 
      metadataPrefix of the included metadata; it must correspond with a value 
      of the metadataPrefix element contained in the ListMetadataFormats 
      element.
      </documentation>
    </annotation>
    <complexContent>
      <extension base="oai:ListRecordsType">
        <attribute name="metadataPrefix" type="oai:metadataPrefixType" use="required"/>
      </extension>
    </complexContent>
  </complexType>

</schema>
This Schema is available at http://www.openarchives.org/OAI/2.0/static-repository.xsd

A1.2 Restricted OAI-PMH XML Schema

Restricted OAI-PMH XML Schema
<schema targetNamespace="http://www.openarchives.org/OAI/2.0/"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:oai="http://www.openarchives.org/OAI/2.0/"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">
  
  <annotation>
    <documentation>This schema restricts the contents a number of elements in
    the OAI-PMH v2.0 schema for use with the static repository schema: 
    http://www.openarchives.org/OAI/2.0/static-repository.xsd
    All elements remain in the namespace http://www.openarchives.org/OAI/2.0/ 
    used by OAI-PMH v2.0 and element instances accepted by these restricted 
    definitions would be valid according to the main schema:
    http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd
    Simeon Warner (Cornell University), 2004-02-12.

    Release: 2004-04-23
    $Date: 2004/05/11 14:40:07 $
    </documentation>
  </annotation> 

  <redefine schemaLocation="http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
   
  <complexType name="ListRecordsType">
    <annotation>
      <documentation>ListRecords block restricted so that it must not include a 
      resumptionToken element.</documentation>
    </annotation>
    <complexContent>
      <restriction base="oai:ListRecordsType">
        <sequence>
          <element name="record" type="oai:recordType" maxOccurs="unbounded"/>
        </sequence>
      </restriction>
    </complexContent>
  </complexType>

  <complexType name="IdentifyType">
    <annotation>
      <documentation>Identify block restricted so that it must not include a 
      compression element. Some element types also restricted.</documentation>
    </annotation>
    <complexContent>
      <restriction base="oai:IdentifyType">
        <sequence>
          <element name="repositoryName" type="string"/>
          <element name="baseURL" type="anyURI"/>
          <element name="protocolVersion" type="oai:protocolVersionType"/>
          <element name="adminEmail" type="oai:emailType" maxOccurs="unbounded"/>
          <element name="earliestDatestamp" type="oai:UTCdatetimeType"/>
          <element name="deletedRecord" type="oai:deletedRecordType"/>
          <element name="granularity" type="oai:granularityType"/>
          <element name="description" type="oai:descriptionType"
                   minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </restriction>
    </complexContent>
  </complexType>

  <complexType name="recordType">
    <annotation>
      <documentation>All records must have header and metadata. As deleted
      records are not supported it is not permissible to have header 
      only.</documentation>
    </annotation>
    <complexContent>
      <restriction base="oai:recordType">
        <sequence>
          <element name="header" type="oai:headerType"/>
          <element name="metadata" type="oai:metadataType"/>
          <element name="about" type="oai:aboutType" 
                   minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
      </restriction>
    </complexContent>
  </complexType>

  <complexType name="headerType">
    <annotation>
      <documentation>The header element must not contain any setSpec elements 
      or a status attribute.</documentation>
    </annotation>
    <complexContent>
      <restriction base="oai:headerType">
        <sequence>
          <element name="identifier" type="oai:identifierType"/>
          <element name="datestamp" type="oai:UTCdatetimeType"/>
        </sequence>
        <attribute name="status" type="oai:statusType" use="prohibited"/>
      </restriction>
    </complexContent>
  </complexType>

  <simpleType name="granularityType">
    <annotation>
      <documentation>The only granularity permitted is YYYY-MM-DD.</documentation>
    </annotation>
    <restriction base="oai:granularityType">
      <enumeration value="YYYY-MM-DD"/>
    </restriction>
  </simpleType>

  <simpleType name="deletedRecordType">
    <annotation>
      <documentation>As deleted records are not supported, the deletedRecord 
      element may only have the value 'no'.</documentation>
    </annotation>
    <restriction base="oai:deletedRecordType">
       <enumeration value="no"/>
    </restriction>
  </simpleType>

  </redefine>
</schema>
This Schema is available at http://www.openarchives.org/OAI/2.0/OAI-PMH-static-repository.xsd

Acknowledgements

Support for the development of the OAI-PMH and for other Open Archives Initiative activities comes from the National Science Foundation through Grant No. IIS-9817416. Individuals who have played a significant role in the development of OAI-PMH version 2.0 are acknowledged in the protocol document.

This Static Repository specification is inspired on the ViDa (Virtual Data Provider) work by Steven Bird and Gary Simons for the Open Language Archives Community (OLAC), a leading community of implementers of the OAI-PMH. Special thanks to Steven Bird and Gary Simons. Thanks also to Pete Johnston, Tim Cole and Tom Habing for helpful comments.

Document History

2004-04-23: Release of Specification for an OAI Static Repository and an OAI Static Repository Gateway.
2003-10-10: Beta Release.
2002-11-13: Alpha release.
2002-09-28: Initial pre-release of this document to core OAI team.