OLAC Repositories

Copyright © 2002 Gary Simons (SIL International) and Steven Bird (University of Melbourne and University of Pennsylvania). This material may be distributed and repurposed subject to the terms and conditions set forth in the Creative Commons Attribution-ShareAlike 2.5 License.

Table of contents

1. Introduction
2. OAI identifier description
3. OLAC archive description
4. Requirements on static repositories
5. Requirements on dynamic repositories

References

1. Introduction

The OLAC standard on metadata repositories is based on the Open Archives Initiative protocol for metadata harvesting [OAI-PMH]. This document assumes familiarity with the OAI protocol. A data provider may take the form of a dynamic repository that implements a CGI interface to query a live database in response to protocol requests, or it may take the form of a static repository that has no interface of its own but is serviced through a static repository gateway [OAI-SR]. OLAC's static repository gateway is named Vida (for "virtual data provider") [Vida].

An OLAC data provider must answer two special description elements as part of the response to the Identify request It must:

• Supply an OAI identifier description

• Supply an OLAC archive description

These elements are described in the next two sections. The remaining sections describe:

• Requirements on static repositories

• Requirements on dynamic repositories

2. OAI identifier description

The resource identifiers supplied by an OLAC data provider must comply with the OAI specification for the format of OAI identifiers as defined in [OAI-Ids]. The data provider must document its compliance with this format by including an <oai-identifier> element within a <description> container in the Identify response.

The schema for validating an OAI identifier description is found at:

http://www.openarchives.org/OAI/2.0/oai-identifier.xsd

In addition to being valid with respect to the schema, these are further requirements on the content of the OAI identifier description:

• The repositoryIdentifier must be unique among all registered OLAC data providers.

• The repositoryIdentifier must be based on a registered domain name, typically of the sponsoring institution. A single institution may use subdomain names to distinguish data providers that are internally distinct.

• The sampleIdentifier must be of an existing item in the data provider, and not a hypothetical item.

For example,

<description>
   <oai-identifier
         xmlns="http://www.openarchives.org/OAI/2.0/oai-identifier"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai-identifier
                    http://www.openarchives.org/OAI/2.0/oai-identifier.xsd">
      <scheme>oai</scheme>
      <repositoryIdentifier>ethnologue.com</repositoryIdentifier>
      <delimiter>:</delimiter>
      <sampleIdentifier>oai:ethnologue.com:AAA</sampleIdentifier>
   </oai-identifier>
</description>

3. OLAC archive description

The basic Identify request supplies minimal information about an archive, namely, its name, base URL, and administrator email. An OLAC data provider must augment the Identify response by including an <olac-archive> element within a <description> container. This element gives additional information that makes it possible for an OLAC service provider to supply its users with a basic description of a participating archive.

The schema for validating an OLAC archive description is found at:

http://www.language-archives.org/OLAC/1.0/olac-archive.xsd

The <olac-archive> element has an obligatory attribute, type, which must have one of two values:

• type="institutional" indicates that the repository is sponsored and operated by an institution

• type="personal" indicates that the repository is sponsored and operated by an individual (or a group of individuals)

These are the elements within an OLAC archive description:

archiveURL

Optional. The home page of the archive on the Web. This is the home page for human visitors, not the base URL for harvesting.

curator

The name of the person who curates the archive collection. If more than one person has collaborated as personal sponsors of the archive, then this element should contain all the names in the order and format the collaborators want to be cited.

curatorTitle

Optional. The job title of the curator within the sponsoring institution (for an institutional archive) or within the institution of affiliation (for a personal archive).

curatorEmail

Optional. A mailto: URI giving the email address for contacting the curator of the archive. (Note that this is distinct from the <adminEmail> in the Identify response which is the contact address for the maintainer of the data provider.)

institution

The name of the sponsoring institution (for an institutional archive) or the institution of affiliation (for a personal archive). The field is obligatory. If the curator of a personal archive has no affiliation, then a value of Unaffiliated should be given.

institutionURL

Optional. A URL for the home page of the institution.

shortLocation

Obligatory. A brief statement of the location of the institution or the person providing the metadata following the format "City, Country". Multiple locations may be connected with "and". This information is shown in the location column of the table of participating archives at http://www.language-archives/archives.php4.

location

Optional. A single paragraph (not to exceed 1000 characters) describing where an archive that houses a collection of physical holdings is located (for instance, include building name, room number, street address). Other information relevant to visiting the collection, such as opening hours or restrictions on access, may also be described. If the archive is purely an on-line repository, do not use this element.

synopsis

A single paragraph (not to exceed 1000 characters) summarizing the purpose, scope, coverage, and so on of the archive.

access

A single paragraph (not to exceed 1000 characters) summarizing terms of access to the materials described in the published metadata. The statement should mention restrictions on access, licensing requirements, costs, and so on. Individual metadata records should use the Rights element to document such things for particular archive holdings. The purpose of <access> is to broadly characterize the entire archive.

For example,

<description>
   <olac-archive
         xmlns="http://www.language-archives.org/OLAC/1.0/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.language-archives.org/OLAC/1.0/
                    http://www.language-archives.org/OLAC/1.0/olac-archive.xsd"
         type="institutional">
      <archiveURL>http://www.ethnologue.com</archiveURL>
      <curator>Raymond G. Gordon, Jr.</curator>
      <curatorTitle>Ethnologue Editor</curatorTitle>
      <curatorEmail>mailto:editor_ethnologue@sil.org</curatorEmail>
      <institution>SIL International</institution>
      <institutionURL>http://www.sil.org</institutionURL>
      <shortLocation>Dallas, USA</shortLocation>
      <location>7500 W. Camp Wisdom Rd., Dallas, TX 75236, U.S.A.</location>
      <synopsis>The Ethnologue data provider gives a metadata record for every
      language entry in the Web edition of the Ethnologue.  The latter provides
      basic information about each of the 7,000+ modern language of the world
      (both living and recently extinct).</synopsis>
      <access>Every resource described by the Ethnologue data provider is a
      public Web page that may be accessed without restriction. Reuse of 
      material on the site is subject to the Terms of Use that are
      posted on the site.</access>
   </olac-archive>
</description>

4. Requirements on static repositories

A static repository is an XML document that describes the resources made available by a particular institution or individual. It is a convenient way to create a data provider for a relatively small collection (say, up to a couple thousand records). Such a document may be created and maintained manually by means of an XML editor. Alternatively, it might be generated periodically by a script that extracts information from an existing database. Typically a given institution or individual should publish the metadata for all its resources in a single static repository. An exception is appropriate when different scripts are used to generate repositories for distinct collections from different databases.

The OAI specification for a static repository is given in [OAI-SR]. The schema for validating a static repository is found at:

http://www.openarchives.org/OAI/2.0/static-repository.xsd

In addition to being valid with respect to this schema, an OLAC static repository must also:

1. Include an <oai-identifier> description and an <olac-archive> description in its <Identify> element.

2. Contain the following element within its <ListMetadataFormats> element:

   <oai:metadataFormat>
      <oai:metadataPrefix>olac</oai:metadataPrefix>
      <oai:schema>http://www.language-archives.org/OLAC/1.0/olac.xsd</oai:schema>
      <oai:metadataNamespace>http://www.language-archives.org/OLAC/1.0/</oai:metadataNamespace>
   </oai:metadataFormat>

3. Contain a <ListRecords> element that specifies an attribute and value of metadataPrefix="olac" and in which every embedded record has a metadata description that conforms to the OLAC metadata standard [OLAC-Metadata].

A Schematron script that can validate a repository for conformance to these requirements is found at:

???

An example of a complete OLAC static repository that conforms to these requirements is found at:

???

5. Requirements on dynamic repositories

A dynamic repository is harder to implement since it requires the implementation of a CGI interface for the complete OAI protocol for metadata harvesting [OAI-PMH]. This is necessary, however, when the collection is large and needs to implement flow control to keep protocol responses to a reasonable size. The OAI community considers half a megabyte to be a reasonable response size. If the ListRecords response for all records in a repository would substantially exceed that size, then it may be necessary to implement a dynamic repository with flow control.

The implementation of a dynamic OLAC data provider has all the features of a minimal repository implementation [OAI-GRI], except that an OLAC data provider need not support the oai_dc metadata format. This is because the OLAC Aggregator [OLACA] provides that service for data providers that comply with this standard. In fact, unless the institution has reasons of its own to function independently as an OAI data provider, OLAC recommends that a dynamic repository not implement the oai_dc metadata format so that the translation of OLAC metadata to the oai_dc format will be done consistently across the community.

In addition to the requirements of a minimal repository implementation, a dynamic OLAC data provider must comply with the following additional requirements.

1. The Identify response must include an <oai-identifier> description and an <olac-archive> description.

2. The ListMetadataFormats response (when made with no additional parameters) must contain a specification for the olac metadata prefix that declares the schema and namespace for the version of OLAC metadata that is being used. For example,

   <oai:metadataFormat>
      <oai:metadataPrefix>olac</oai:metadataPrefix>
      <oai:schema>http://www.language-archives.org/OLAC/1.0/olac.xsd</oai:schema>
      <oai:metadataNamespace>http://www.language-archives.org/OLAC/1.0/</oai:metadataNamespace>
   </oai:metadataFormat>

3. When the metadataPrefix argument to ListIdentifiers is specified as olac, the request must respond with at least one record.

4. When the metadataPrefix argument to GetRecord is specified as olac, the <oai:metadata> element of the response must either be empty (when no OLAC metadata is available for the given identifier) or it must contain an <olac:olac> element that conforms to some version of the XML schema for OLAC metadata [OLAC-Metadata]. That element must contain an xmlns attribute specifying the URI that identifies the namespace for the version of the OLAC metadata schema that is being used.

5. When the metadataPrefix argument to ListRecords is specified as olac, every <oai:metadata> element in the response must contain an <olac:olac> element that conforms to some version of the XML schema for OLAC metadata [OLAC-Metadata]. Each such element must contain an xmlns attribute specifying the URI that identifies the namespace for the version of the metadata schema that is being used.

To do

References