Metacat OAI Provider

From Dryad wiki
Revision as of 10:01, 27 August 2009 by Ryan Scherle (talk | contribs) (Project Plan)

Jump to: navigation, search

Status: In progress at UNM

UNM is creating an OAI-PMH provider to add on to Metacat. The core Metacat code is available from the Ecoinformatics SVN. This work will integrate directly into the Metacat development tree.

Project Final Report

The project final report provides background and details on the implementation of the provider.


  • Our primary goal is to enhance access, not to provide a failover copy. It is ok for Dryad to only store the Dryad-format metadata, and not use the full EML.
  • Metacat exposes all metadata through an OAI-PMH provider.
  • The provider makes all data available in these formats:
  • Dryad harvests all metadata exposed by Metacat.
    • The record in Dryad must point to the record in Metacat, enabling users to find the actual datasets.
  • Metacat harvests metadata from the Dryad OAI-PMH provider, and makes it available alongside the native Metacat metadata.
  • The design of the OAI-PMH "adapter" should provide a more generalized interface that supports cross-walking other metadata standards to/from Metacat beyond just EML.
  • Not an actual requirement, but keep in mind that we need to eventually download the data files.

Answered Questions

  • Should any "sets" be defined in the provider? Is there any natural breakdown of the MetaCat data into categories?
    • Identity of data provider (which LTER site)
  • Is there any need to convert from simple DC to EML?
    • This is desirable in the long run, but may not be needed for the immediate project.
  • UNM can send us the metacat XSL, so we can display EML "properly" if we want. Is there any reason Dryad should display the EML in a more Metacat-like manner?
    • Depends on Dryad's approach to displaying contents from other repositories. We probably don't want to display this directly in Dryad, just display the portion of the metadata that fits Dryad, and then link out to the "real" site.
  • How should harvested content be stored/displayed in Dryad?
    • The vast majority of datasets in Metacat do not have direct relationships with publications.
    • Metacat does have "aggregations" of data, but these could easily be represented as individual records (as we are doing with the DC records).
    • Hilmar suggests that for non-publication data, we create a separate section of search results listed as "related content in other repositories"
  • Do the rights statements on Metacat files affect Dryad's ability to make the metadata searchable? Probably not, if we always redirect users to the Metacat item pages.

About Metacat

All Metacat items have an ID with the following parts:

  • scope (knb-lter, esa)
  • identifier
  • revision

Metacat supports "simple" URLs with the format:

  • knb-lter-nin.24402 is the ID
  • lter is the presentation format

Metacat supports LSID with the format:

  • LSID resolving is "only local" (not remote metacat servers?)
  • LSID is used as the accession number by ESA, but what do other sites use?

Mailing list is at

About EML

The EML schema documents (EML 2.0.1) can be downloaded at (note that there is a new revision, EML 2.1, of the schema due to be released this Spring).

EML examples:

station at Brunswick, Georgia for 1915 to 2004.

Data in EML that has no logical place in the Dryad Application Profile:

  • description of dataset size, encoding, table format, implementation details
  • details of fields within the dataset
  • geographic bounding boxes (Note: After further discussion, Ryan suggested that we should map the four bounding coordinates, each in its own coverage element. -- Duane Costa, 3/10/2009)
  • processing method
  • software
  • author/organization distinction
  • access control