This is a working document. A final version will be posted when discussions are completed.

To Do:

  • Better define all proposed dcterms, provide scope notes and examples (what is allowable and what is not)
    • As a practice if an element is CORE we will attempt to enforce conformity of values to a certain standard.  If Not Quite Core, we will not attempt to enforce conformity to any standard.
  • Determine if it is possible to “re-map” Dome or use the new terms going forward
  • Ask Carl if reports are possible (asked on 1/26 – he’s looking into it) - Received 02/8

  • Research use of dcterms:mediator

To Discuss:

Question 1 for Carl: Can/How do we move the contents of a field into another field?  How do we do it en masse? See question 3 for Carl.

Question 2 for Carl: Is it significantly different or more difficult to map just field at a time rather than multiple fields?

Question 3 for Carl: What is the difference in changing fields within a namespace versus migrating all the fields to a new namespace? We found that you can move metadata fields from one schema to the other within the dome metadata registry editing module.

Good Question 1 How will our recommended changes to the DOME metadata registry affect indexing in DOME

Good Question 2: How will our changes affect metadata harvesting, either through OAI-PMH, Google, or other harvesters.

It sounds like this is a good candidate for a MIT Libraries Project Proposal.

It also sounds like we need to put together a plan of attack. What changes to make how and when.

We should add some fields from VRA core in dome-test and put together a metadata record that contains metadata from multiple schemas to see how it looks in DOME.

We may want to identify pieces of this list of DOME adjustments that we can fast track to assist new collections going into DOME.

dc.contributor.attribute

Considering mapping all custom contributor fields to dcterms:contributor and creating an agent display field that would display names with associated roles

Custom Contributor Fields

  • .advisor = 1 use (can be mapped to dcterms:contributor with no problems)
  • .author = 4488 uses (Question: will mapping to dcterms:contributor create duplicate names in that field?  Can we dedup this field after mapping?)
  • .editor = 0 uses
  • .illustrator = 0 uses
  • .other = 99 uses (can be mapped to dcterms:contributor with no problems)

Even if we do not decide to go to dcterms:contributor we should:

  • immediately cease using custom contributor fields
  • map custom contributor fields to existing dc.contributor.none field (Question: Is it significantly different or more difficult to map just a few fields rather than the whole set)

We want to go ahead and recommend the addition of a custom name display field to aggregate all names and roles.  This field would need to be established in our custom "dome" namespace.  This field would be included in the brief record in DOME.  While consolidating contributor fields can be accomplished programmatically, it may prove difficult to generate display fields for items already deposited in DSpace.  All items from Rotch will already have a display field (currently in the dc.creator field -- we may want to migrate this metadata to the new display field before we start consolidating contributor fields).  Archives has information in their METS export that could be used to produce the display name field.  This information is currently not being put in DOME.  For existing items, it would need to be concatenated and added to the records.

dcterms: available vs. dc.date.accessioned

both are DSpace system dates.  Is this duplication necessary? Do we care?  DSpace will automatically populate both fields unless the filed is already populated prior to deposit.  dc.date.accessioned is the date the system took in the item.  dc.date.available is intend for use with embargoed items.

dcterms: datecopyrighted vs. dcterms: issued

issued will be used for the publication date of formally published items.  Do we need to know when something was copyrighted if it is different from the date issued?

dcterms:created for non-published items

dcterms:issued for published items

both dcterms:created and dcterms:issued are indexed

We will use dcterms:datecopyrighted for items that different copyright and publication dates.  dc.date.datecopyrighted has never been used in DOME. While possible, it will be likely seldom used.  We do not think that it is enough that an item only has a dcterms:datecopyrighted field.  It must have either a dcterms:created or dcterms:issued field, the dcterms:datecopyrighted is strictly supplemental.

dcterms: date vs. dcterms:created and dcterms:issued vs. dcterms:temporal

Do we want to use this field as a display field for all the various dates that can be associated with an item?

We want a date display field(s) for various kinds of date expressions and items with multiple associated dates that need to be concatenated.  Candidates are dcterms:date, dcterms:temporal, dcterms:created, dcterms:issued and dcterms:date We want to allow various collections to follow their own cataloging rules in choosing the date format.

  • When describing the coverage of an item (the date as the subject) use dcterms:temporal.
  • When concatenating a bunch of dates use a dome:dates field (to be added to metadata registry in custom dome namespace, the namespace is also used of displaying multiple authors and roles).
  • 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.

We need a solution that does not require significant editing of metadata export from source repositories, nor significant programming/scripting/processing by the deposit mechanism/process.

DomeCORE “Notes” elements (No further action needed)

Use dcterms:abstract for those things that are formally abstracts, dcterms:tableOfContents for tables of contents, dcterms:description for all else.  At least one of dcterms:abstract, dcterms:description, or dcterms:tableOfContents is required to satisfy the DOME Core MD Requirement.  Most items will have descriptions.

dcterms:identifier and dcterms:identifier.other

We are discussing using two identifier fields, one for an official identifier (not assigned by DOME), and identifier.other for all other types of identifiers.  Should this field remain qualified after metadata table update?  We think it should, but are unsure of how to accomplish that.  We choose to keep the practice of using separate fields for primary identifiers, secondary identifiers and the DOME handle.  What we want to do is move the secondary and handle fields from our to a custom dome namespace/schema.

dc.identifier.attribute

Map all the various custom identifier fields to dome:otherIdentifier (except for dc.identifier.uri)

dc.identifier.uri

This is where the handle goes.  Map to dome:URI

dc.identifier.vendorcode

Used for visual items from IRIS. Can this be mapped into dome:otherIdentifier?  Yes.

We need to be able to distinguish between the DOME assigned handle, the primary identifier assigned previous to deposit in DOME, and all other identifiers assigned previous to deposit.  Currently no secondary identifier needs its own custom field. This may change in the future.

The dcterms namespace contains just one flavor of identifer, dcterms:identifiers.  Any qualification or customizations would need to be made in our custom dome namespace.  dcterms:identifier is indexed for search

Use dc.identifier for the primary identifier assigned previous to deposit in DOME.  This identifier is usually assigned by the system used to catalog the items prior to deposit or by the cataloger according to the particular policy of the collection being cataloged.

For the DOME assigned Handle use dome.URI defined in our custom dome namespace. Question for Carl: if we move Handles to our custom dome namespace will this affect the harvesting of metadata from DOME via the OAI-PMH or other protocols.

For all other identifiers assigned previous to deposit in DOME use dome:otherIdentifier defined in our custom dome namespace.

---- Stopped here 2011-02-08 ----

dcterms:language

(asking Carl for usage report) If it does not cause any major issues, we recommend merging dc.language.iso with dc.language.

dc.language is never used. We will map dc.language.iso to dcterms:language.

dc.relation.ispartofseries

(asking Carl for usage report) recommend merging this with dc.realation.ispartof = dcterms:isPartOf

dc.relation.ispartof is used 236 times

dc.relation.ispartofseries is used 4271 times

as far as we know only in the 'MIT Whirlwind' and 'Communications Forum' communities.  Items in these communities are often assigned multiple dc.relation.ispartofseries.

There should be no problem in migrating dc.relation.ispartofseries to dcterms:isPartOf along with dc.relation.ispartof

 

dc.relation.type

map to VRA relation type instead of a dcterm

This field has not been used in DOME and it is misnamed.  The intended element comes from the VRA Core schema and should be named '[whatever the vra namespace prefix is]:worktype'. We will add this element in a new VRA schema to be added to the metadata registry in DOME.

dc.relation.type should be removed from the dc schema in DOME

dcterms:accessRights

Core or Not Quiet Core? Answer: Not Quite Core pending further information from legal counsel.

dc.rights.uri vs. dcterms:rights

Primarily used for creative commons licenses. Do we really need a separate field for this or can we just put the URIs in the regular rights field.

dc.rights.uri is not used in DOME, we would like to remove that field.  Any future copyright URIs can go into dcterms:rights.

dc.subject.attribute

map all custom subject fields to dcterms:subject

dc.subject has 37 uses

dc.subject.lcsh has 304909 uses

dc.subject.classification has 0 uses

dc.subject.ddc has 0 uses

dc.subject.lcc has 0 uses

dc.subject.mesh has 0 uses

dc.subject.other has 111788 uses.  This field contains AAT terms, some LCSH headings, College and University Thesaurus terms.  Since it is already a catch all and not every lcsh heading is included in the dc.subject.lcsh field, the custom DOME qualifications carry little meaning.  We would like to collapse them all to dcterms:subject.

dcterms:type

We need to revise the current type vocabulary.  We would like to adopt a practice of mandatory assignment of value from our controlled vocabulary and optional assignment from other vocabularies.  Should the optional type values be entered in a separate field?

Todo: Identify the one vocabulary that we will use for the DOME Core type field.  This vocabulary will be mapped to dcterms:type.

When a type vocabulary is defined within a specificaiton (for example, VRA Core type) use the identified field within that schema (Adding the schema and field to the Dome metadata registry).

For type vocabularies that are not defined within a metadata specification (for example, local type vocabularies) we will use a 'localType' (need to find a better name) element in our homegrown DOME metadata schema.

Todo: Separate all the different vocabularies from the dc.type field.  This will be messy.

---- Stopped here 2011-02-15 ----

dcterms:publisher.institution

added to identify MIT Libraries/Archives as the content holder or distributor (could also be an MIT DOME scheme?)

also looking into the use of dcterms:mediator as a possible option

dc.format.support

use VRA

For Carl:

Usage reports for:

  • dc.descripiton.sponsorship & dc.description.statementof responsibility (we are leaning toward removing these fields)
  • dc.description.uri
  • dc.format.mimetype (Is this an internal DSpace field?)
  • dc.language.iso (system use?)
  • dc.relation.isbasedon (We recommend renaming this element to the dcterms standard “dcterms:source”.  This may conflict with another md field “dc.source.uri”.)
  • dc.relation.ispartofseries (We recommend merging this with dc.relation.ispartof.)

Other:

  • Why are 55 and 56 both dc.source.uri  & are these fields being used?

Metadata Terms:

(List does not include elements listed above in the questions “to discuss”)

 DomeCORE:

dcterms:contributor

dcterms:creator

dcterms:description

dcterms:abstract

dcterms:tableofcontents

dcterms:identifier

dcterms:issued

dcterms:created

dcterms:rights

dcterms:title

dcterms:type

NotQuiteCORE:

dcterms:spatial

dcterms:temporal

dcterms:provenance

dcterms:extent

dcterms:medium

dcterms:format

dcterms:bibliographicCitation

dcterms:language

dcterms:publisher

dcterms:hasPart

dcterms:hasVersion

dcterms:isFormatOf

dcterms:isPartOf

dcterms:source

dcterms:isReferencedBy

dcterms:isReplacedBy

dcterms:isVersionOf

dcterms:replaces

dcterms:requires

dcterms:relation

dcterms:subject

dcterms:alternative

New NotQuiteCore:

dcterms:conformsTo

dcterms:hasFormat

dcterms:isRequiredBy

dcterms:references

  • No labels