Difference between revisions of "Mapping MODS to OAI DC"
Jump to navigation
Jump to search
Kleinfercher (talk | contribs) m (→Comment) |
Kleinfercher (talk | contribs) m (→Format Name) |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
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. | 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. | ||
<br/> This mapping basically reflects the [http://www.loc.gov/standards/mods/mods-dcsimple.html mapping recommended by the Library of Congress]. | <br/> This mapping basically reflects the [http://www.loc.gov/standards/mods/mods-dcsimple.html mapping recommended by the Library of Congress]. | ||
==Format Name== | |||
'''Source:''' MODS <br/> | |||
'''Target:''' oai_dc | |||
==Mapping== | ==Mapping== | ||
{|border="1" | {|border="1" | ||
|- bgcolor="# | |- bgcolor="#C1CDCD" | ||
! width="200" |'''[http://www.loc.gov/standards/mods/ MODS] Element''' | ! width="200" |'''[http://www.loc.gov/standards/mods/ MODS] Element''' | ||
! width="200" |'''[http://www.dublincore.org/documents/dces/ Dublin Core Metadata Element]''' | ! width="200" |'''[http://www.dublincore.org/documents/dces/ Dublin Core Metadata Element]''' | ||
| Line 15: | Line 19: | ||
|- | |- | ||
|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. | |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. | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|order|| --|| | |order|| --|| -- | ||
|- | |- | ||
|subject|| Subject || | |subject|| Subject || | ||
| Line 41: | Line 45: | ||
|- | |- | ||
|originInfo.dateOther|| Date || | |originInfo.dateOther|| Date || | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|originInfo.edition|| --|| | |originInfo.edition|| -- || | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|originInfo.place.placeTerm || | |originInfo.place.placeTerm || Publisher || Add to Publisher, separated by comma | ||
|- | |- | ||
|typeOfResource|| Type || Use separate instances of Type for each MODS element value. | |typeOfResource|| Type || Use separate instances of Type for each MODS element value. | ||
| Line 57: | Line 61: | ||
|- | |- | ||
|form|| Format || | |form|| Format || | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|recordInfo.recordIdentifier|| | |recordInfo.recordIdentifier|| --||Not mapped, as institute specific <br/> example: <recordIdentifier source="mab001">515624</recordIdentifier> | ||
|- | |- | ||
|identifier|| Identifier || It is suggested that the identifier type be retained and associated with the identifier value. | |identifier|| Identifier || It is suggested that the identifier type be retained and associated with the identifier value. | ||
|- | |- | ||
|location.URL|| Identifier || | |location.URL|| Identifier || | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|location.physicalLocation|| | |location.physicalLocation|| --|| Not mapped, as institute specific <br/> example: Dt 9 Bg 20 Q [8] | ||
|- | |- | ||
|language|| Language || | |language|| Language || | ||
| Line 73: | Line 77: | ||
|- | |- | ||
|accessCondition|| Rights || | |accessCondition|| Rights || | ||
|-bgcolor="# | |-bgcolor="#FFC1C1" | ||
|copyInformation|| 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== | ==Other LoC Formats== | ||
| Line 81: | Line 87: | ||
==Comment== | ==Comment== | ||
* If we provide export of ViRR metadata in oai_dc and/ or marc21 it must be clear | * 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 [[ViRR_and_METS| mets]] export. | ||
==General Information== | ==General Information== | ||
| Line 88: | Line 94: | ||
* [http://www.loc.gov/standards/mods/mods-dcsimple.html Mapping from Library of Congress] | * [http://www.loc.gov/standards/mods/mods-dcsimple.html Mapping from Library of Congress] | ||
* [[Meta_Object_Description_Schema | MODS in CoLab]] | * [[Meta_Object_Description_Schema | MODS in CoLab]] | ||
* If we can do it without escidoc specific mapping parts we can also use the [http://www.loc.gov/standards/mods/MODS3-22simpleDC.xsl xsl provided by the LoC]. (Differences are | * If we can do it without escidoc specific mapping parts we can also use the [http://www.loc.gov/standards/mods/MODS3-22simpleDC.xsl xsl provided by the LoC]. (Differences are <font color="#FFC1C1"> colored </font>) | ||
* [[MAchine-Readable_Cataloging_(MARC)| MARC in CoLab]] | |||
Latest revision as of 11:45, 28 July 2009
|
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[edit]
Source: MODS
Target: oai_dc
Mapping[edit]
| 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[edit]
We can also provide ViRR metadata in MARC21 format, as there is a transformation already provided (mods2marc21).
Comment[edit]
- 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[edit]
- 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