From oaibp

Jump to: navigation, search

Main Page >> Data Provider Implementations

[edit] Introduction

Note: Added link to OAI tools list and did copy editing. Naomi Dushay 02/09/06

[edit] What you will find in the Best Practices for OAI Data Provider Implementations

The Best Practices for Open Archives Initiative (OAI) Data Provider Implementation is divided into four main parts:

  • this Introduction which provides background information for this section;
  • Managing the Repository Lifecycle which offers general guidelines for various stages in the lifecycle of an OAI repository;
  • Best Practices for OAI Data Provider Implementations which includes recommendations for implementation of many pieces of the OAI protocol;
  • Functional Requirements and Best Practices which includes a breakdown of required pieces for an OAI data provider, optional pieces, and best practices.

A fourth section contains:

  • Links to Reference Documents which are important to understanding the protocol and which are referred to throughout this section.

Throughout we have tried to offer specific, concrete best practices and guidelines whenever possible. However, certain sections do present either a range of choices or a spectrum of best practices from ideal to acceptable. These often represent an acknowledgement of the diversity and range of capabilities within the OAI community, and, in some cases, areas where a best practice has not clearly evolved. In each section, we provide a basic overview of the protocol definition of the concept, but we do assume a certain practical knowledge of the OAI protocol. We highly recommend that readers have read through the OAI protocol and the Implementation Guidelines.

We also recommend:

We have not offered assessments of any particular flavor of OAI data provider within these best practices. Many OAI data providers are freely available (the OAI Tools page at and/or a search on SourceForge will turn up many), and many digital content management systems now include a built-in OAI data provider. We do plan to offer a checklist that can be used to assess the functionality of a data provider.

Readers interested in creating or modifying metadata for use within the OAI protocol should refer to the Best Practices for Shareable Metadata.

[edit] Why best practices for OAI data provider implementations are necessary

The OAI protocol requires relatively few pieces for implementation: valid responses to OAI verbs, the use of oai_dc (Simple Dublic Core) as a metadat format, unique and persistent OAI identifiers, and a datestamp for each item. The OAI Guidelines for Implementation have a limited technical scope, are intended for a general audience of implementers, and do not describe the benefits and consequences of some of the optional features of the protocol. This has meant that many useful features of OAI, such as multiple metadata formats, sets, descriptive containers, etc., that are helpful for service providers have been underutilized or have remained unimplemented by data providers. This can be particularly true of OAI data providers built into digital content management systems.

These best practices for OAI data provider implementations are based on the experiences of well established service providers and data providers. Our goal is to provide a useful set of guidelines for both organizations implementing a stand-alone OAI data provider as well as vendors and software developers who are responsible for OAI data providers included within larger systems.

Personal tools