Dome Metadata Application Rules

Contributor Elements - Discussed

1. Custom contributor fields (dc.contributor.illustrator, dc.contributor.advisor, dc.contributor.author, dc.contributor.editor, dc.contributor.other) will no longer be used in Dome metadata.
2. Existing custom contributor field will be consolidated to the dcterms:contributor (dc.contributor.none) element.
3. Either dcterms:contributor or dcterms:creator (dc.creator.none) must be present in an Item's metadata to satisfy the Dome Core MD Requirement.
4. A new element will be added to the Dome metadata registry (domecustommd:namesDisplay(?dc.contributor.other)). It will be established in a new "Dome" namespace that we will create for our custom elements. It will aggregate all of the contributor names, dates and roles associated with an Item.  It is intended to be used in brief Item records in DOME.  The aggregated contributor information will be provided by depositing repositories upon import.

Carl's Comments

1. For rule 2, we need to figure out how we can do this?  We've never done this before. We've changed the contents of a field, but haven't changed the field name without changing the content. Can Bill's ItemUpdater utility do this?
2. For rule 4, we need to figure out how we can do this as well? Carl will look at Bill's ItemUpdater to see if it can accomplish this.

The way ItemUpdater works is you feed it a dublincore.xml file you prepare in advance that contains the changes you would like to make.  So we would need to reexport all of these records out of IRIS.

? How do we evaluate the ROI(?) value added(?) in making these changes?

How to accomplish rules 2 and 4

Step 1: Enable the field for use by future collections deposited to Dome.

Step 2: On a collection by collection basis, identify the field that currently contains the aggregated contributor information to go into custommd:namesDisplay, if it exists (this should exist for Rotch collections, but not Archives).  Then we need to migrate the contents from the current field to custommd:namesDisplay. Migration means doing the following:

We would accomplish these changes on a collection by collection basis. We would need to reexport metadata from IRIS for those Dome records we would like to adjust. We would identify this IRIS metadata by order number and dspace handle fields.  We would prepare the dublincore.xml file that the ItemUpdater requires from this exported metadata.  This dublincore.xml field would also contain the instructions for removing the metadata fields that we are seeking to replace in existing Dome Item records.

Step 3: For collections that do not have a field with all of the names, roles, dates concatenated, add it.  -- If we reimport we can grab and add where name fields don't exist.

Step 4: Strip date and role information for all names in dc.contributor.none and dc.creator.none fields. -- Too hard and variable across collections, just replace all the name metadata instead.

The easiest way to accomplish all of this is to reimport names for all Items in Dome by grabbing the right fields from IRIS or AT and replacing the current contributor and creator fields with the newly exported values from IRIS or AT.  We still want to do this collection by collection.

Date Elements

1. dcterms:issued (dc.date.issued) will be used for the publication date of formally published Items.
2. dcterms:created (dc.date.created) will be used for the creation date of non-published Items.
3. Either dcterms:issued or dcterms:created must be present in an Item's metadata to satisfy the Dome Core MD Requirement.
4. When describing the coverage of an Item (the date as the subject) use dcterms:temporal (dc.coverage.temporal).
5. dcterms:datecopyrighted (dc.date.copyright) will be used for Items with different copyright and publication dates.
6. dcterms:available (dc.date.available) will be used for embargoed Items.
7. dcterms:accesioned (dc.date.accessioned) will only be used by the DSpace system.
8. dcterms:date (dc.date.none) will be used for all other dates.
9. A new element will be added to the Dome metadata registry (dome:dates(?)).  It will be established in a new "Dome" namespace that we will create for our custom elements. It will aggregate all the various kinds of dates associated with an Item.
10. When including multiple kinds of dates (for example, the date a photograph was taken and the date the content of the photograph was created) choose the most important date and put in either dcterms:created or dcterms:issued.  Put other dates in dcterms:date or in dcterms:temporal.

...

1. dcterms:identifier (dc.identifier.none) will be used for an Item's primary identifier, assigned prior to deposit in Dome.
2. Custom identifier fields (dc.identifier.govdoc, dc.identifier.isbn, dc.identifier.ismn, dc.identifier.issn, dc.identifier.sici, dc.identifier.vendorcode) will no longer be used in Dome.
3. Existing custom identifier fields will be consolidated to a new element that will be added to the Dome metadata registry (domecustommd:otherIdentifier(?dc.identifier.other)). The new element will be established in a new "Dome" namespace that we will create for our custom elements.
4. dc.identifier.uri will only be used by the DSpace system to record the Handle it assigns to the Item. Can it be mapped to a new element (dome:URI(?)) in the newly established "Dome" namespace that we will create for our custom elements? Answer: No. Will moving this field to a new namespace cause problems for external harvesters of Dome metadata?  Answer: Carl says we'd probably run into problems moving this field, he can't for certain, but it is highly likely.  Solution: We will leave handles in dc.identifier.uri.

?What steps need to be taken to bring the existing use of identifier fields in Dome into compliance with the above rules, especially multiple instances of dcterms:identifier (dc.identifier.none)? 

Existing practice in Dome almost matches our rules. Minimally: All we need to do is map customs to dc.identifier.other. Preferrably: Move dc.identifier.other to custommd:otherIdentifier

Language Elements

1. dc.language.iso will no longer be used in Dome.
2. Existing dc.language.iso fields will be mapped to dcterms:language (dc.language.none).

...