You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Dome Metadata Application Rules

Contributor Elements

  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 (dome:namesDisplay(?)). 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.

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.

We need to determine how prescriptive we need to be in controlling the syntax of the various date fields.  THIS IS THE MOST IMPORTANT QUESTION  We need to ask Carl how best to use date ranges and other kinds of date expressions (for example, ca. 1976) in indexed date fields. Carl thinks this field is indexed as a string of text.  We are leaning towards unconcern over the indexing of date fields and the allowance of what ever kind of date expression is most appropriate for the content being described.  We are also considering restricting dcterms:created and dcterms:issued to single dates and ranges, reserving dome:dates for ca., approx., etc.

? What steps need to be taken to bring the existing use of date fields in Dome into compliance with the above rules?

Notes Elements

  1. Use dcterms:abstract (dc.description.abstract) for formal abstracts.
  2. Use dcterms:tableOfContents (dc.description.tableofcontents) for formal tables of contents.
  3. Use dcterms:description (dc.description.none) for all other notes or descriptions.
  4. At least one of the above three elements are required to satisfy the Dome Core MD Requirement.
  5. The following fields will no longer be used in Dome (dc.description.sponsorship, dc.description.statementofresponsibility, dc.description.uri).

?What steps need to be taken to bring the existing use of note fields in Dome into compliance with the above rules, especially rule 5?

Need Usage Reports for

  1. dc.description.sponsorship
  2. dc.description.statementofresponsibility
  3. dc.description.uri

Identifier Elements

  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 (dome:otherIdentifier(?)). 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? Will moving this field to a new namespace cause problems for external harvesters of Dome metadata?

?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)?

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).

Relation Elements

Rights Elements

  1. dc.rights.uri will no longer be used in Dome (there are currently no populated dc.right.uri fields).

Subject Elements

  1. Custom subject fields (dc.subject.lcsh, dc.subject.classification, dc.subject.ddc, dc.subject.lcc, dc.subject.mesh, dc.subject.other) will no longer be used in Dome metadata.
  2. Existing custom subject fields will be consolidated to the dcterms:subject (dc.subject.none) element.

Type Elements

Metadata Manipulation Notes

There are a few different kinds of actions:

  1. Move data from one field to another within the existing dc namespace (for example custom contributor fields).
  2. Move data from a field within the existing dc namespace to a field in a newly created namespace (for example custom identifier fields).
  3. Import new metadata for existing Items into fields in a newly created namespace (for example concatenated/aggregated dates).
  4. Parse data in an existing fields and separate it into multiple fields, some into existing fields in the dc namespace, some into new fields in a newly created namespace (for example identifier and type fields).
  5. Move all of the elements in the existing dc namespace into a new dcterms namespace.
  • No labels