Skip to page content.

Please note: This experimental research project has concluded.
The research prototype application is no longer supported or maintained by OCLC services, and information on this page is provided for historical purposes only. Some portion of this content may be out-of-date and include broken links. Please visit the OCLC Research website to learn more about our current research.

Extensible Repository Resource Locators (ERRoLs) for OAI Identifiers

Table of Contents

1. Introduction
2. Supported OAI Repositories
3. Item ERRoLs with oai-identifiers
    3.1. Examples
4. Item ERRoLs with Other Identifiers
    4.1. Examples
5. Repository ERRoLs
    5.1. Examples
6. Coordinating Content in OAI Repositories
7. OAI Viewer
    7.1. Examples
8. Caveats
9. Credits
10. Contact

1. Introduction

An ERRoL is a "Cool URL" to metadata, content, and services related to registered Open Archive Initiative (OAI) repositories. Following the examples below, anyone can create/use a Cool URL to any metadata record or web resource related to supported OAI repositories.

2. Supported OAI Repositories

Any OAI repository can use the ERRoL service by registering a unique repository identifier with the OAI Registry at UIUC.

3. Item ERRoLs with oai-identifiers

Because repository identifiers are embedded in oai-identifiers by definition, the simplest ERRoL patterns work for repositories that utilize them. The "Core ERRoL" pattern for an item in a repository looks like this (examples are here, here, and here if you just can't wait):

  • "http://errol.oclc.org/" +
    Produces an HTTP redirect to that item's oai_dc OAI GetRecord response from the "home repository" (as defined by the OAI Registry at UIUC).

"Extended ERRoLs" resolve to related content, metadata, and services for this item and are constructed by adding various extensions to the Core ERRoL shown above. In general, these Extended ERRoLs will look something like this:

  • "http://errol.oclc.org/" + + ".html"
    Produces an integrated HTML view of the record within the context of the home repository.
  • "http://errol.oclc.org/" + + "." +
    Returns the raw content of the OAI GetRecord response for that metadataPrefix without the OAI wrapper elements.
  • "http://errol.oclc.org/" + + ".ListMetadataFormats"
    Produces an HTTP redirect to the OAI ListMetadataFormats request for that item in the home repository.
  • "http://errol.oclc.org/" + + ".resource"
    Produces an HTTP redirect to the URL found in the first resolvable dc:identifier of the oai_dc record (or to the oai_dc OAI GetRecord response itself if no usable dc:identifier is found). This service is a variation of the PURL-based Object Identifier (POI) scheme. The ERRoL ".resource" version provides the same basic functionality, but using a slightly different URL scheme.
  • "http://errol.oclc.org/" + + ".ListERRoLs"
    Produces a complete list of available extensions that can be appended to the Core ERRoL to produce these various results.

Note that the ".resource" extension is an effective substitute for PURLs and Handles. Rather than create a PURL or Handle and reference it in your catalog record, you can store the target URL itself in the first dc:identifier field of an oai_dc record and use the Extended ERRoL ".resource" extension to resolve to the content. When the URL changes, you simply update the dc:identifier with the new location and the ".resource" ERRoLs automatically pick up the change as part of their intrinsic operation. Doing it this way cuts out the PURL and Handle middlemen.

Also note that the list of Extended ERRoLs can be customized for individual OAI repositories. Contact Jeff Young for details.

3.1. Examples

Without further ado, here is an example of a Core ERRoL and a few of its Extended ERRoLs.

4. Item ERRoLs with Other Identifiers

This works fine for repositories that use the oai-identifier scheme to identify items in its collection, but for those that don't, a repository identifier needs to be embedded in the ERRoL since it can't be parsed from the item identifier. Review the list of supported repositories to determine the "repositoryIdentifier" for those that don't use the oai-identifier scheme. In this case, the Core ERRoL pattern is:

  • "http://errol.oclc.org/" + + "/" +

As in the oai-identifier case above, this Core ERRoL produces an HTTP redirect to that item's oai_dc OAI GetRecord response from the specified repository. The same mechanism for constructing Extended ERRoLs by appending extensions also applies.

4.1. Examples

5. Repository ERRoLs

The ERRoLs above demonstrate the possibilities for accessing information about items in a repository, but you can also construct ERRoLs for a repository itself. The Core ERRoL pattern for a repository is:

  • "http://errol.oclc.org/" +

In this case, the repository's Core ERRoL acts as a surrogate for the official baseURL of the repository. This is achieved by performing an HTTP redirect to the real baseURL passing along any arguments that are included. While this form can be used by harvesters, it is an indirect path and thus isn't optimal. On the other hand, it is convenient for performing manual interactions in a browser. There are many possibilities for Extended ERRoLs at the repository level too. Here are some examples:

  • "http://errol.oclc.org/" + + ".html"
    Returns an interactive HTML view of the respository
  • "http://errol.oclc.org/" + + ".v10"
    A surrogate for the official baseURL converting the repository's native response into an OAI-PMH v1.0 response
  • "http://errol.oclc.org/" + + ".v11"
    A surrogate for the official baseURL converting the repository's native response into an OAI-PMH v1.1 response
  • "http://errol.oclc.org/" + + ".v20"
    A surrogate for the official baseURL converting the repository's native response into an OAI-PMH v2.0 response
  • "http://errol.oclc.org/" + + ".rss"
    Converts the OAI repository into an RSS feed
  • "http://errol.oclc.org/" + + ".ListERRoLs"
    Provide a complete list of ERRoLs available for this repository

5.1 Examples

6. Coordinating Content in OAI Repositories

If you are questioning the need to resolve to the raw content of an OAI GetRecord element using the "." + qualifier, this section should show its potential.

In the example that follows, I have an OAI repository (baseURL: http://alcme.oclc.org/xmlregistry/OAIHandler) that not only contains the oai_dc metadata describing an XML Schema, but also the XML Schema itself under a different metadataPrefix ( xsd). The Core ERRoL, in this case isn't nearly as interesting as one of the Extended ERRoLs.

As you can see, the Extended ERRoL resolves to a usable copy of the XML Schema document with no apparent clue that it is anything other than a static document on the web. In fact, though, the document is being ripped out of the OAI GetRecord response before being sent back to a client that may not even parley OAI (e.g. a web browser in this case).

Taking this one step further, there is also an XHTML document describing the schema sitting along side under the xhtml metadataPrefix.

If you're still skeptical of the value of storing XML content alongside metadata in an OAI repository like this, review the OpenURL Registry which makes extensive use of these same concepts (but using an earlier and comparatively crude implementation based on PURL partial redirects and embarrassing "extensions" to OAI).

7. OAI Viewer

The OAI Viewer service provides an interactive browser display of a repository based on the available OAI verbs. It can be accessed using ".html"-type Extended ERRoLs or by selecting from the list of supported repositories on the ERRoL home page. The OAI Viewer works by issuing Identify, ListSets, ListMetadataFormats, GetRecord, and ListMetadataFormats(identifier) requests to the home repository and consolidating them into a single interactive HTML response.

Note that it is possible for repositories to configure the look-and-feel and include custom services in the OAI Viewer display. Contact Jeff Young for details.

7.1 Examples

8. Caveats

  1. This service works in association with the OAI Registry at UIUC, which is dedicated to the OAI community as a whole. To have this resolver work with your repository, go there to register.
  2. It can be seen from the list of registered repository identifiers that some are not unique across repositories. "GenericEPrints" and "GenericEPrints.OAI2" are particularly ambiguous. If this is the case with your repository, you can contact the OAI Registry at UIUC to have a unique repository identifier assigned so you can at least use the explicit repository identifier pattern of ERRoLs with your generic oai-identifiers.
  3. Likewise, registered repositories that don't use the oai-identifier scheme will need to have some sort of repositoryIdentifier associated with it before the explicit repository identifier pattern will work for them. Unfortunately, many of the repositories that Tom inherited don't have such an identifier. In this case, you can contact Tom Habing at UIUC to get a repositoryIdentifier assigned.
  4. After looking at the oai_dc metadata for the XHTML and XSD examples discussed above, don't be clever and store a ".resource" ERRoL in the first dc:identifier of your oai_dc records. The ".resource" ERRoLs operate by performing an HTTP redirect to the first dc:identifier in the oai_dc record, so storing a ".resource" ERRoL there can cause a circular HTTP redirect. You can, however, store any of the other "." + -type ERRoLs there, if you wish, to describe an item stored as XML content under a different metadataPrefix.
  5. This resolver currently works with OAI-PMH v1.1 and v2.0 repositories only. If you would like to use this resolver with a repository based on some other version, contact me.

9. Credits

Thanks to Andy Powell and Thom Hickey for their collaboration on POIs, which I think make this resolver service particularly exciting.

Thanks to Herbert Van de Sompel for his ideas about storing XML content in OAI repositories.

Thanks to Herbert and the NISO AX Committee for the OpenURL for the opportunity to experiment with the integration of XML content, "Cool URLs" for OAI requests, XSLT rendering of OAI responses, and POIs, in the innovative and surprisingly simple OAI-based implementation of the Registry for the OpenURL Framework. My only regret is that I didn't think of this resolver sooner so that I could have avoided the two non-OAI extensions that I added to OAICat (for POI and raw metadata response support) and all those messy PURLs.

And special thanks to Tom Habing for the OAI Registry at UIUC that inspired this service and for responding so quickly to my request to make it OAI harvestable. His registry make this resolver possible. Thanks Tom!

10. Contact

Send comments and suggestions to Jeff Young at the OCLC Office of Research.