Difference between revisions of "Metacat OAI Provider"
From Dryad wiki
Ryan Scherle (talk | contribs) (→Tasks) |
Ryan Scherle (talk | contribs) (→Requirements) |
||
| Line 12: | Line 12: | ||
** The record in Dryad must point to the record in Metacat, enabling users to find the actual datasets. | ** 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. | * 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. | * Not an actual requirement, but keep in mind that we need to eventually download the data files. | ||
Revision as of 12:00, 26 February 2009
UNM is creating an OAI-PMH provider to add on to Metacat. The core Metacat code is available from the Ecoinformatics SVN. LTER maintains a local copy, which will be used for initial development of the OAI-PMH provider.
Contents
Requirements
- 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:
- Simple DC
- Dryad application profile (qualified DC with extensions)
- EML
- 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.
Tasks
- Ryan/Mark: schedule a bi-weekly call to touch base on progress.
- Ryan: discuss with Matt Jones (and Mark?) how to ensure that we're implementing things in a way to will work well for other Metacat installations.
- Ryan: work with MRC to determine "ideal" Dryad records.
- Duane: Create XSL to convert EML -> simple DC.
- Duane: Create XSL to convert EML -> Dryad application profile.
- Duane: Create XSL to convert dryad application profile -> EML.
- Ryan: Evaluate quality of simple DC and Dryad application profile records, suggest modifications to XSL.
- Duane: Complete/create OAI-PMH provider functionality in LTER Metacat.
- Depending on status of current Metacat functionality, either complete existing implementation, or integrate a new system such as OCLC's OAIcat, a UIUC provider, or the DLESE provider.
- Note: There is no existing OAI-PMH implementation for Metacat (per Matt Jones).
- Depending on status of current Metacat functionality, either complete existing implementation, or integrate a new system such as OCLC's OAIcat, a UIUC provider, or the DLESE provider.
- Ryan: Configure harvest of Metacat metadata and test metadata availability in Dryad.
- Duane/Mark: Move OAI-PMH provider code from LTER to core Metacat.
- Note: In discussions with Matt Jones, work will integrate directly into the Metacat development tree from the project beginning; such integration will avoid version mis-match with the Metacat development head and provide project plan transparency for Metacat developers.
- Duane: Install an OAI-PMH harvester at LTER and configure to harvest from the Dryad provider.
- Possible implementations include OCLC's OAIHarvester2, the UIUC harvester, and the DLESE harvester.
Open Questions
- Should any "sets" be defined in the provider? Is there any natural breakdown of the MetaCat data into categories?
- Is there any need to convert from simple DC to EML?
- 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?
About EML
The EML schema documents (EML 2.0.1) can be downloaded at http://knb.ecoinformatics.org/software/download.html#eml (note that there is a new revision, EML 2.1, of the schema due to be released this Spring).
EML examples:
- Georgia Coastal Ecosystem LTER (knb-lter-gce.247.9.xml): Annual summaries of daily climatological observations from the National Weather Service weather
station at Brunswick, Georgia for 1915 to 2004.
- North Temperate Lake LTER (knb-lter-ntl.110.2): Lake Metabolism in North Temperate Lakes.
- Andrews Experimental Forest LTER (knb-lter-and.3185.4.xml): Role of vegetation and coarse wood debris on soil processes and mycorrhizal mat distribution patterns at the Hi-15, Andrews Experimental Forest.
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
- processing method
- software
- author/organization distinction
- access control
