Print

Print


I've copied your text below and inserted my comments.

Thanks for getting this start-- we will work on developing this into a
mapping that we can put up.

I do think there are other DC qualified elements that MODS elements will
map to. Perhaps for now we should stick to simple DC, since I didn't think
this was complete in terms of qualified, i.e. dcterms:

MODS to Dublin Core Mapping

By Dublin Core Element, from MODS Element

Title:
//mods/titleInfo/title - A conditional IF statement is included to catch
<titleInfo><subTitle> and append it to the title, separated by colon space
(: ).

RG: You need to deal with multiple titles and alternative titles. Karen
has already mentioned this and I agree-they need to be kept in order and
all be strung together in DC.
I would also string together the other pieces (see below).

Creator:
//mods/name/namePart -  when //mods/name/role[. = 'creator']
//mods/recordInfo/recordContentSource

RG: DC does not deal with "metametadata" and the second one is not
appropriate at all; this is creator of the record.

Subject:
//mods/subject/topic
//mods/subject/name
//mods/subject/titleInfo/title

RG: MODS subject can have any number of subelements in any order, so the
DC value should concatenate them all in one string retaining the
order. Punctuation between them is an issue; if the authority is LCSH,
then you can assume double dashes between each subelement.

Description:
//mods/abstract
//mods/tableOfContents
//mods/note
//mods/subject/name<description>

RG: I wouldn't include subject/name<description>.  Description associated
with subject/name cannot really exist on its own. I would probably drop it
(and of course put the subject/name with Subject or just append it to
subject name.

Publisher:
//mods/originInfo/publisher
//mods/publicationInfo/publisher - to accommodate earlier encoding
practices; this usage is outdated

Contributor:
//mods/name/namePart -  when //mods/name/role/text[. = 'contributor']

RG: There are a few ways to do this; it's difficult to map because of the
distinction in DC between Creator and Contributor. There has been much
discussion (especially in the DC-Usage Board) about using only Contributor
and not Creator, but some people got upset, so that was left open. One way
to do this is to to use Contributor for any name/namePart with a role
other than creator specified. The other way is to decide to map all
name/nameParts to Creator and not use contributor. I would think that the
role with value "contributor" would almost never be used, since it doesn't
add anything. If this were done as you suggest, then there would be no
place for anything that doesn't have role=creator or role=contributor in
MODS. And most probably will have something other than these 2 (or
nothing).

Date:
Mapped from:
//mods/originInfo/dateIssued
//mods/originInfo/dateCreated
//mods/originInfo/dateCaptured
//mods/originInfo/dateOther
//mods/publicationInfo/dateIssued - to accommodate earlier encoding
practices; this usage is outdated

Type:
//mods/typeOfResource
//mods/genre

Format:
//mods/physicalDescription/extent
//mods/physicalDescription/form
//mods/physicalDescription/internetMediaType
//mods/physicalDescription/digitalOrigin
//mods/physicalDescription/note

RG: I would put physicalDescription/note in Description. Not sure that
there's a good place for digitalOrigin; could cram it in either here or
note.

Identifier:
//mods/identifier - If @TYPE= 'isbn', 'issn', 'lccn', 'doi' or 'uri', then
this value precedes the data, separated by colon space.

Example:        <identifier>uri: http://www.ucpress.edu/books/pages/6178.html&amp;isbn=0520081994</identifier>
        If there is no TYPE attribute, or if it is not set to one of these
values, the data is mapped without qualification.

RG: Since MODS 3.0 now makes a distinction between identifier and
location, <location><url> needs to map to DC identifier. URI usually
doesn't precede the data, so I'm not sure that this helps as you specify
above.

Source:
//mods/relatedItem[@TYPE='original']

Language:
//mods/language

Relation:
//mods/relatedItem - except when relatedItem[(@TYPE='original') or
(@TYPE='series')]

Coverage:
Mapped from:
//mods/subject/geographic
//mods/subject/temporal
//mods/subject/hierarchicalGeographic
//mods/subject/cartographic
//mods/classification
        The hierarchicalGeographic and cartographic nodes are flattened so
that repeating values as well as sub-elements (and their children) are
strung into one element.

RG: why classification?? Classification goes under Subject in DC.

Rights:
//mods/accessCondition

DCTerms:Abstract:
//mods/abstract - this data is also mapped (see above) into Description,
so that data is not lost in Unqualified Dublin Core.

DCTerms:Created
//mods/recordInfo/recordCreationDate.  This is also mapped to Date, so
that data is not lost in Unqualified Dublin Core.

RG: no, this is metadata about the record, and dc:created is about the
resource. Same as mods:dateCreated

DCTerms:Modified
//mods/recordInfo/recordChangeDate.  This is also mapped to Date, so that
data is not lost in Unqualified Dublin Core.

RG: same thing; dc:modified is the date the resource was modified, not the
metadata. Same as mods:dateModified (v. 3)

DCTerms:isPartOf
//mods/relatedItem - when //mods/relatedItem[@TYPE='series'].  This is
also mapped to Relation, so that data is not lost in Unqualified Dublin
Core.

RG: Also, mods/relatedItem type=host

There are other DC qualified elements that have mappings (especially
under relation).

By MODS Element, to Dublin Core Element

ELEMENT MAPPED TO
//mods/titleInfo/title                          title
//mods/titleInfo/subTitle                       title
//mods/titleInfo/partNumber                     ignored
RG: I would concatenate with the rest of the title information.
//mods/titleInfo/partName                       ignored
RG: same as above.

(Left off the rest, since already covered above.)

Rebecca