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&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
