Secondary menu

Hamilton College > Library > Digital Collections

You are here

Mapping CONTENTdm Metadata to Dublin Core

Field Name
Nickname

DC Mapping
[data type]

MARC
WC-DCG
Title
title (qdc)
Title
245
wc.Title
Title Type (h)
titype
none
none
none
Expanded Title (h)
tinon
Title-Alternative
none
none
Alternative Title
titlea (qdc)
Title-Alternative
246
wc.OtherTitle
Object Class (AAT)
wortyp
Type
520 [8 ]
wc.Summary
ETD Statement
etd
Description
none
none
Abstract*
abstra
Description-Abstract
520 [3 ]
wc.Abstract
Table of Contents*
table
Description-Table Of Contents
505?
wc.Contents
Description
descri
Description
520 [8 ]
wc.Summary
Creator
creato (qdc)
Creator
100
wc.Author
Creator Role
creata
none
none
none
Contributor
contri (qdc)
Contributors
720
wc.All Authors/Contributors
Contributors Note
contno
Description
520 [8 ]
wc.Summary
Date date Date [text] ? wc.Date (?)
Date (h)
dateh (qdc)
Date [date]
none
none
Date Note
datnot
Description [text]
520 [8 ]
wc.Summary
Text (h-varies)
text
None[full text]
none
none
Text Extracts (h)
struct (YYY)
None
none
none
Inscriptions*
inscri
None
none
none
Language
langua (qdc)
Language
546
wc.Language
Medium - Original (AAT)
materi
Format
none
none
Techniques (AAT)
techna
Format
none
none
Physical Description
physic
Format
none
none
Series*
series
Description
none
none
Edition*
editio
Description
520 [8 ]
wc.Summary
Publisher - Original
publis (qdc)
Publisher
786 [08]
none
Production Note
produc
Description
none
none
Subjects
subjec (qdc)
Subject
650
none
Concepts (AAT)
subaat
Subject
650
none
Tags
subtag
Subject
none
none
Locations (LCSH)
covera (qdc)
Coverage-Spatial
522
none
Years Covered (h)
covdat (Date)
Coverage-Temporal [date]
648
none
Personal Names
person
Subject
653
none
Corporate Names
corpor
Subject
653
none
Source
source (qdc)
Source
786 [08]
none
Holder of Original*
holder
Source
786 [08]
none
Original Collection*
oricol
Source
786 [08]
none
Shelf Locator*
origid
Source
786 [08]
none
Digital Publisher
digpub
Publisher
260 $b
wc.Publisher
Identifier
identi (qdc)
Identifier
none
none
Digital Repository
reposi
None
none
none
Digital Collection
relati (qdc)
Relation-Is Part Of
787
wc.Series
Digital Collection Link
colink
None
787
wc.Series
Virtual Collections
virtual
Relation-Is Part Of
none
none
Copyright Status Code (h)
rights
Rights-Access Rights
none
none
Copyright Note
righta
Rights-Access Rights
540
wc.Responsibility
Printed Rights Statement
printe
Rights-Access Rights
none
none
Rights Holder (h)
cophol
Rights-Rights Holder
none
none
Year Copyrighted (h)
copdat
Date-Copyrighted
none
none
Embargo Date (h)
embarg
none
none
none
Access Rights
access
Rights-Access Rights
none
none
Use and Reproduction
usepol
Rights-Access Rights
none
none
License
licens
Rights-License
none
none
Contact
contac
None
540
wc.Responsibility
Processing History
techni
None
none
none
Type of Resource (DCMI)
type (qdc)
Type
655
wc.Genre/Form
Medium - Digital (MIME)
format
Format.Medium
340
none
Extent - Digital
digita --> deprecate
Format.extent
300
none
Extent - Digital Images
extimg
Format.extent
300
none
Extent - Digital Audio
extaud
Format.extent
300
none
Extent - Digital Video
extvid
Format.extent
300
none
Extent - Digital Text
exttxt
Format.extent
300
none
Encoded Text
encode
none
none
none
Provenance (h)
proven
Provenance
none
none
Donor (h)*
donor
Provenance
none
none
Evidence Level (h)
eviden
Description
none
none
Cataloging Level (h)
catalo
none
none
none
Internal Notes (h)
intern
none
none
none
Submitter (h)*
submit
None
none
none
URL (Persistent Identifier)
 
Identifier [system supplied]
856 $u
none

*Add "(<field name>)" after value, e.g. "sme-05032 (Original Item ID)" in order to keep meaning clear after exporting.

 

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

- Top -

(Reviewed: October 4, 2013)