IdentifyResponse

From oaibp

Jump to: navigation, search

Main Page >> Data Provider Implementations

Contents

[edit] Identify Response

[edit] Protocol Definition

The Identify response is issued by an OAI repository in response to the Identify verb.

The OAI-PMH 2.0 specifies that the Identify response must contain one instance of the following:

  • repositoryName : a human readable name for the repository;
  • baseURL : the base URL of the repository;
  • protocolVersion : the version of the OAI-PMH supported by the repository;
  • earliestDatestamp : a UTCdatetime that is the guaranteed lower limit of all datestamps recording changes, modifications, or deletions in the repository. A repository must not use datestamps lower than the one specified by the content of the earliestDatestamp element. earliestDatestamp must be expressed at the finest granularity supported by the repository. See the Best Practices for Datestamps for more information on datestamps.
  • deletedRecord : the manner in which the repository supports the notion of deleted records. Legitimate values are no ; transient ; persistent with meanings defined in the section on deletion. See the Best Practices for Deleted Records for more information on deleted records.
  • granularity: the finest harvesting granularity supported by the repository. The legitimate values are YYYY-MM-DD and YYYY-MM-DDThh:mm:ssZ with meanings as defined in ISO8601. See the Best Practices for Datestamps for more information on granularity.

The Identify response must include one or more instances of the following:

  • adminEmail : the e-mail address of an administrator of the repository.

The response may include multiple instances of the following:

  • compression : a compression encoding supported by the repository. The recommended values are those defined for the Content-Encoding header in Section 14.11 of RFC 2616 describing HTTP 1.1. A compression element should not be included for the identity encoding, which is implied.
  • description : an extensible mechanism for communities to describe their repositories. For example, the description container could be used to include collection-level metadata in the response to the Identify request. Each description container must be accompanied by the URL of an XML schema describing the structure of the description container.

See the protocol specifications on the Identify response: http://www.openarchives.org/OAI/openarchivesprotocol.html#Identify

See section 3.1 of the Implementation Guidelines for more information on the optional description containers: http://www.openarchives.org/OAI/2.0/guidelines.htm

[edit] Best Practices for the Identify Response

It is a best practice for OAI data providers to keep Identify responses accurate and up to date.

Best Practices for Mandatory Elements

  • repositoryName: a human readable name for the repository. The repositoryName is often used by service providers to quickly identify possible repositories to harvest and may be used to identify the origin of records within whatever system a service provider builds. Thus the repositoryName should give the name of the repository, identify the organization responsible for the repository if applicable, and whenever possible give a clue as to the content of the repository. Examples of good repositoryNames are: The Journal of Community Informatics and Caltech Computer Science Technical Reports.
  • baseURL: the base URL of the repository. The base URL should be kept current. See Managing the Repository Lifecycle for more information on handling a change to the base URL.
  • protocolVersion: the version of the OAI-PMH supported by the repository. The current version is OAI 2.0.
  • earliestDatestamp: lower limit of all datestamps recording changes, modifications, or deletions in the repository. See the Best Practices for Datestamps for more information on datestamps.
  • adminEmail: the e-mail address of an administrator of the repository. The Identify response may contain multiple instances of adminEmail. This value allows service providers to communicate with data providers when they encounter difficulty in harvesting or to report other problems. The value should be a plain email address such as someone@somewhere.org and not a mailto: URI. The adminEmail should include the email of the person responsible for the implementation and maintenance of the repository. In addition, the email address of the person responsible for the records exposed by the OAI repository is also useful. In any case, the administrator should be able to respond to problems and questions or direct service providers to the appropriate person. Please note, that many digital library management systems that include an OAI repository include a default value in the adminEmail element. This should be updated to the appropriate email address.

Best Practices for Optional Elements

  • compression: As stated above, this element contains a compression encoding supported by the repository. The recommended values are those defined for the Content-Encoding header in Section 14.11 of RFC 2616 describing HTTP 1.1. A compression element should not be included for the identity encoding, which is implied. It is a best practice that the OAI repository include the encodings they support in this element. See Section 3.1.3 of the OAI Protocol and Section 7 of the Implementation Guidelines for Repository Implementors.
  • description: The description container allows data providers to describe various aspects of the OAI repository. As stated in the OAI protocol, each description container must be accompanied by the URL of an XML schema describing the structure of the description container. There are several such schemas available and described within Section 3.1 of the OAI Implementation Guidelines. These are described more fully below, but it should be noted that the description container is extensible and other schemas may be used.

[edit] Best Practices for Use of the Description Container

Descriptive Information

It is a best practice to include a description of the OAI repository within the Identify response particularly if the repository does not support sets or does not include set descriptions. The repository description should include such information as the type of resources described by the metadata in the respository, how often the repository is updated, documentation about metadata practices, etc. This type of administrative information is often important for service providers in determining whether and how often to harvest an OAI repository and what post-harvest processing to perform on the metadata. It is possible to provide such a description using the simple Dublin Core schema.

Community-specific guidelines were developed for ePrint repositories for which it is a best practice to define a metadata policy, a submission policy etc. See http://www.openarchives.org/OAI/1.1/eprints.xsd. Other communities such as the OLAC community have developed their own schema to describe repositories. See http://www.language-archives.org/OLAC/1.0/olac-archive.xsd.

The following is an example of an ePrint description. 

    <description>
    <eprints xsi:schemaLocation="http://www.openarchives.org/OAI/1.1/eprints
    http://www.openarchives.org/OAI/1.1/eprints.xsd">
    <content>
    <URL>http://cds.cern.ch/</URL>
    </content>
    <metadataPolicy>
    <text>Free and unlimited use by anybody with obligation to refer to original record</text>
    </metadataPolicy>
    <dataPolicy>
    <text>Full content, i.e. preprints may not be harvested by robots</text>
    </dataPolicy>
    <submissionPolicy>
    <text>Submission restricted. Submitted documents are subject of approval by OAI repository admins.</text>
    </submissionPolicy>
    </eprints>
    </description>

Friends

An OAI repository can refer to related repositories by using the Friends schema (http://www.openarchives.org/OAI/2.0/friends.xsd). Use of this schema allows service providers to find other repositories that might be of interest. As an example, the NASA repository mentions a number of friends: 

    <description>
    <friends xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/friends/ 
    http://www.openarchives.org/OAI/2.0/friends.xsd">
    <baseURL>http://techreports.larc.nasa.gov/ltrs/oai2.0/</baseURL>
    <baseURL>http://naca.central.cranfield.ac.uk/cgi-bin/nph-oai.cgi</baseURL>
    <baseURL>http://ston.jsc.nasa.gov/collections/TRS/oai/</baseURL>
    <baseURL>http://trs.nis.nasa.gov/perl/oai/</baseURL>
    <baseURL>http://naca.larc.nasa.gov/oai2.0/</baseURL>
    <baseURL>http://eprints.riacs.edu/perl/oai/</baseURL>
    <baseURL>http://celestial.eprints.org/cgi-bin/oaia2/arXiv.org</baseURL>
    <baseURL>http://www.biomedcentral.com/oai/2.0/</baseURL>
    <baseURL>http://www-dev.osti.gov/oai2.0/</baseURL>
    <baseURL>http://genesis2.jpl.nasa.gov/perl/oai</baseURL>
    <baseURL>http://www.giss.nasa.gov/cgi-bin/gpol2/</baseURL>
    </friends>
    </description>

OAI Identifier

See the Best Practices for OAI Identifiers section for a discussion of the OAI Identifier format.

Branding

An OAI repository can provide a logo for service providers to display alongside their metadata records. Service providers may choose to ignore the branding information; data providers may want to contact likely service providers to see whether or not such branding is useful. See also Branding Repositories and Sets. 

    <description>
    <branding xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/branding/ 
    http://www.openarchives.org/OAI/2.0/branding.xsd">
    <collectionIcon>
    <url>http://memory.loc.gov/ammem/oamh/lc-icon.gif</url>
    <link>http://www.loc.gov</link>
    <title>Library of Congress</title>
    <width>100</width>
    <height>35</height>
    </collectionIcon>
    <metadataRendering metadataNamespace="http://www.loc.gov/MARC21/slim" mimeType="text/xsl">
    http://www.loc.gov/standards/marcxml/xslt/MARC21slim2HTML.xsl
    </metadataRendering>
    </branding>
    </description>

Toolkit

A data provider may include a description of the toolkit used in the OAI repository. This information may be useful to service providers in determining the technical capabiltiies of the OAI repository. 

    <description>
    <toolkit xsi:schemaLocation="http://oai.dlib.vt.edu/OAI/metadata/toolkit 
    http://oai.dlib.vt.edu/OAI/metadata/toolkit.xsd" xmlns="http://oai.dlib.vt.edu/OAI/metadata/toolkit">
    <title>OCLC's OAICat Repository Framework</title> 
    <author>
    <name>Jeffrey A. Young</name> 
    <email>jyoung@oclc.org</email> 
    <institution>OCLC</institution> 
    </author>
    <version>1.5.42</version> 
    <toolkitIcon>http://alcme.oclc.org/oaicat/oaicat_icon.gif</toolkitIcon> 
    <URL>http://www.oclc.org/research/software/oai/cat.shtm</URL> 
    </toolkit>
    </description>

Rights

The data provider may include a rights manifest statement at the OAI repository level. See the section on About Containers and Expressing Rights over Metadata for more information.

Retrieved from "http://webservices.itcs.umich.edu/mediawiki/oaibp/index.php/IdentifyResponse"
Personal tools