Mapping MODS to OAI DC

Virtueller Raum Reichsrecht Overview Functionalities Support Copyright and Disclaimer Scope Metadata: Application Profile · Content Models Metadata Display · ViRR Metadata Action Matrix Transformations: virr 2 mets · mab 2 mods mods 2 oai dc · mods 2 marc21 Specification Intern: Meetings · GUI · Miscellaneous Development · Planning · Feedback Related Projects: Judicial Journals · Late Scholasticism Digitization Lifecycle edit

The following specifies the mapping of MODS metadata, which are part of the escidoc metadata record for ViRR items to Dublin Core metadata. This transformation will be exploited for the OAI-PMH interface of the ViRR solution.
This mapping basically reflects the mapping recommended by the Library of Congress.

Format Name

oai_dc

Mapping

MODS Element	Dublin Core Metadata Element	Comment
titleInfo.title	Title	For multiple MODS titles use multiple instances of dc:title. MODS allows <titleInfo> subelements to be parsed: <nonSort>, <title>, <subTitle>, <partNumber>, <partName> MODS subelements should be concatenated in Dublin Core, separated by a space or other form of punctuation.
name.namePart	Creator	MODS allows <name> subelements to be parsed: <namePart>, <displayForm>, <affiliation>, <role>, <description> MODS subelements should be concatenated in Dublin Core, separated by a space or other form of punctuation.
order	--	--
subject	Subject
subject.topic	Subject
subject.name	Subject
classification	Subject
abstract	Description
note	Description
tableOfContents	Description
originInfo.publisher	Publisher
originInfo.dateIssued	Date
originInfo.dateCreated	Date
originInfo.dateCaptured	Date
originInfo.dateOther	Date
originInfo.edition	--
originInfo.place.placeTerm	Publisher	Add to Publisher, separated by comma
typeOfResource	Type	Use separate instances of Type for each MODS element value.
genre	Type
physicalDescription	Format	Use separate instances of Format for each MODS element value.
internetMediaType	Format
extent	Format
form	Format
recordInfo.recordIdentifier	--	Not mapped, as institute specific example: <recordIdentifier source="mab001">515624</recordIdentifier>
identifier	Identifier	It is suggested that the identifier type be retained and associated with the identifier value.
location.URL	Identifier
location.physicalLocation	--	Not mapped, as institute specific example: Dt 9 Bg 20 Q [8]
language	Language
relatedItem	Relation	If type="constituent", a full description may be given under relatedItem and conversion may result in an incomprehensible value. Alternatively, an application may wish to map only some elements under <relatedItem>, e.g., <titleInfo> and <identifier> or <location> if a full MODS description is given. For example, if giving a reference to a resource fully described in MODS relatedItem, one could use: <relatedItem><identifier> and/or title of a resource: <relatedItem><titleInfo><title>
accessCondition	Rights
copyInformation	Rights

For start we will go with the provided transformation from LoC. All coloured metadata will not be in this mapping, but this will be fine for start. we can enhance the transformations at a later stage.

Other LoC Formats

We can also provide ViRR metadata in MARC21 format, as there is a transformation already provided (mods2marc21).

Comment

• If we provide export of ViRR metadata on the user interface in oai_dc and/ or marc21 it must be clear that the export in this format only contains bibliographic metadata. For exporting structural metadata one has to use mets export.

General Information

• Metadata Object Description Schema (MODS)
• Dublin Core Metadata Elements V1.1
• Mapping from Library of Congress
• MODS in CoLab
• If we can do it without escidoc specific mapping parts we can also use the xsl provided by the LoC. (Differences are colored )
• MARC in CoLab

Metadata Object Description Schema

Virtueller Raum Reichsrecht

Open Archives Initiative Protocol for Metadata Harvesting

Uniform Resource Locator