Mapping CONTENTdm Metadata to Dublin Core

CONTENTdm Metadata and OAI-PMH

• Field Name (= element label) - This is our local label for the metadata element, which often does not correspond to the equivalent field name it is mapped to in Dublin Core, but we have set up our metadata schema in CONTENTdm with the following goals in mind:

  1. Provide a basic set of metadata elements that is rich enough to facilitate fine-grain digital object management and strong fielded searching.
     • This required that we create several elements in addition to the standard Qualified Dublin Core Metadata Elements.
  2. Ensure interoperability with OAI-PMH-based systems (and the WorldCat Digital Collection Gateway).
     • To this end we labeled our metadata elements in CONTENTdm in ways that make mapping them to the OAI-PMH schema as easy as possible whenever feasible.
  3. Ensure that as many fields as possible are exposed to OAI-PMH harvesters.
• DC Map - This column lists the Dublin Core element names used by CONTENTdm for internal purposes. This mapping is also used when contributing data to the World Cat Digital Gateway and OAI-PMH harvesters.
  • A field is mapped to "none"
    • When it is not appropriate to expose it to World Cat Digital Gateway or OAI-PMH harvesters such as
      • when the field is useful only within some local context (such as administrative metadata)
      • when the use of the field stretches the Dublin Core guidelines
    • When you do not need to offer searching on a field.
  • A field is mapped to "dc:source"
    • When it is desireable to expose its value to OAI-PMH harvesters, but it does not map precisely to any Dublin Core field. We use dc:source as a garbage label.
       
• To facilitate efficient OAI Harvesting ....
  • Map to as many Qualified Dublin Core elements as you can, instead of to just Simple Dublin Core elements in order to maximize exposure of your metadata.
  • Map just one instance of the following fields "date," "type," and "format" (unless you use a qualifier) otherwise you will risk confusion and misunderstanding in the OAI-PMH environment:
  • Avoid mapping a field with a highly specific custom label to a more generic Dublin Core element (such as dc:description, dc:source, dc:type, or dc:format) unless the values they contain can be easily understood on their own without the custom label. If necessary, prefix the values with a context term as we do for the "Original Item ID ("Accession number of Original: ...").
  • We store metadata in CONTENTdm about only digital objects, so we are careful not to map fields holding information about physical objectds to Dublin Core elements that would be better used to describe the digital object.
  • A CONTENTdm field is mapped to "none" when the records are being exported to an OAI-PMH file format when the field stretches Dublin Core guidelines and might interfere with interoperability in a federated environment.
  • Dublin Core elements that use standard controlled vocabularies are good candidates for exposing to OAI harvesters.
  • *If an element is not mapped to Dublin Core it will not be used by an OAI harvester.
  • If a field is set to "hidden" in CONTENTdm, it will be hidden from CONTENTdm end users even if it is mapped to a Dublin Core element. But when it comes to exporting data, you have to be sure that the method you choose exports hidden fields if that is what you want. You may have to un-hide them before exporting them. Normally OAI-PMH harvesters do not see hidden fields in CONTENTdm so you do have to un-hide them if you want to expose them to OAI-PMH harvesting..
    For example, because the Date (h) field is hidden in CONTENTdm, it will not be found by some OAI-PMH harvesters even if it is mapped to dc:date. It will be exported if you choose to export the records using the Dublin Core or CONTENTdm Standard export methods.
    However, OCLCDC does not permit mapping to fields that are designated as hidden in CONTENTdm. So if you intend to export your data to OCLC's Digital Gateway (i.e., WorldCat) do not hide elements that you will want OCLC to harvest.
     
• For the World Cat Digital Collection Gateway
  • You must map fields in CONTENTdm to a Dublin Core element if you want them included in WC-DCG.
  • If a field is set to Hidden in CONTENTdm, it will also be hidden from WC-DCG.
  • If a field is set to Searchable in CONTENTdm, it will also be searchable in WC-DCG.

CONTENTdm OAI Configuration Options

• [No] "Enable compound object pages"

DC Export from CONTENTdm

• [check] "Repeat fields that use identical XML tags"
• [check] "Repeat fields that contain multiple terms."

OAI Best Practices (formatting the element values)

• Some harvesters may dumb down Qualified Dublin Core to Simple Dublin Core and as a result some element values may be merged that you would not have expected to be. If there is a semicolon at the end of these fields, then when they are merged they will be properly separated.
  • dc:description.tableOfContents and dc:description.abstract
  • dc:coverage.spatial and dc:coverage.temporal
  • dc:subject
  • dc:rights
  • dc:relation (including Digital Repository, Digital Repository Link, Digital Collection, Digital Collection Link, etc.)
  • Actually, there's no harm in putting a semicolon at the end of the values for every field.
  • To avoid this problem entirely, you could map only one CONTENTdm field to each simple Dublin Core element, or ensure that there is a semicolon at the end of any fields that may be merged.
• It is not necessary to put semicolons after unique fields (i.e., only one instance per record) such as...
  • Title
  • Original Item ID

• To Do in all collections
  • Delete ETD Statement, Edition, Table of Contents, Style/Period if not needed in a collection.
  • Publisher - Show both digital and original publishers
    • John Kimball Photography, Utica, New York (original publisher). Digital version provided by the Hamilton College Library, Clinton, New York.

Resources on CONTENTdm and OAI-PMH

• Best Practices for CONTENTdm and other OAI-PMH compliant repositories: creating shareable metadata (OCLC), October 22, 2010
  <http://www.contentdm.org/USC/forum/download/file.php?id=36> (login required) (accessed October 4, 2013)
   
• Best Practices for Shareable Metadata (Digital Library Federation)
  <http://webservices.itcs.umich.edu/mediawiki/oaibp/index.php/ShareableMetadataPublic (accessed October 4, 2013)
   
• Beyond theory: preparing Dublin Core metadata for OAI-PMH Harvesting, by Amalia Beisler and Glee Willis (official version: Journal of Library Metadata 9(1-2):65-97, January 2009), DOI: 10.1080/1938638090309509 (preprint: <http://contentdm.library.unr.edu/digitalprojects/BeislerWillis.pdf> (accessed October 4, 2013)
   
• Data Dictionaries (a.k.a. Schemas and Metadata Application Profiles or MAPS) (University of Washington, Libraries)
  <http://www.lib.washington.edu/msd/mig/datadicts/default.html> (accessed October 4, 2013)
   
• Metadata for Special Collections in CONTENTdm: How to improve interoperability of unique fields through OAI-PMH, by Myun-Ja Han, et al. (Journal of Library Metadata 9:213-239, 2009). DOI: 10.1080/19386380903405124
  <https://www.ideals.illinois.edu/bitstream/handle/2142/15415/WJLM.pdf> (accessed October 4, 2013)

(Reviewed: October 4, 2013)