Versions Compared

Old Version 8

changes.mady.by.user rwolfe@mit.edu

Saved on

compared with

New Version 9

changes.mady.by.user rwolfe@mit.edu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note: Do we want to officially recommend as the Metadata Operations Team that we start enforcing compliance with LC NAF in the choice of form of author name.

Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx)

Date Elements - Discussed

...

3. Data cleanup will follow the same general procedure as names, that is, reexporting dates from IRIS and AT in the format that we need them and them reimporting the metadata to existing Items and replacing the current date fields. Date field cleanup (rexport and import) will be more complicated and less of a priority than names.

Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx)

Notes Elements - Discussed

...

All we just need to do is move the one dc.description.sponsorship to dc.description.none and sort the 1719 existing dc.description.abstract fields, leaving the proper abstracts in the field and moving all others to dc.description.none.  We sorted these on 2011-05-20, found that all 1719 uses of the field occurred in the Project Whirlwind collection and decided to just leave them there.

Example: N/A

Identifier Elements - Discussed

...

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

Example: N/A (same as subjects in Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx))

Language Elements - Discussed

...

We haven't yet actually proposed keeping the contents of a filed and just changing the name. Do we want to follow the name/date procedure and replace current language fields with new fields from a reexport from contributing repositories? Certainly, this field's data cleanup is not the highest priority. Carl says if we are already reexporting/reimporting name and date fields, especially since we'll probably have to do this for every record, it will not add much effort or complexity to add this field in with the rexport/reimport.

Relation Elements

Example: N/A (same as subjects in Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx))

Relation Elements -- Discussed

  1. dc.relation.ispartofseries will be mapped to dcterms:dc.relation.ispartofseries will be mapped to dcterms:isPartOf (dc.relation.ispartof)
  2. The following relation elements will be added to the dcterms (or dc.) namespace dcterms:conformsTo (dc.relation.conformsTo), dcterms:hasFormat (dc.relation.hasFormat), dcterms:isRequiredBy (dc.relation.isRequiredBy), and dcterms:references (dc.relation.references) will be added to the dublin core schema.  These elements exist in the dublin core standard, but are missing from the Dome metadata registry.
  3. dc.relation.isbasedon will be mapped to dcterms:source (dc.relation.source.none).  There is no dcterms:isbasedon element.  We will leave dc.source.uri in the dc metadata schema for DSpace to use during OAI PMH export or harvesting.  DSpace uses the field to attach its own name as the source for items it exports or has harvested.
  4. dc.relation.uri will be mapped to dcterms:relation (dc.relation.none)
  5. dc.relation.type will be mapped to vra(?):worktype is not used and will be removed from the schema.  The information for which the field was intended will be assigned to a worktype element in a new VRA Core schema that will be established in the Dome metadata registry.

We need to understand how DSpace uses the dc.source.none and dc.source.uri fields to avoid any conflict in mapping dc.relation.isbasedon to dc.source.none.

...

Our approach to enforcing Rules 1 and 4 will be similar to the custom identifier fields, dc.language.iso, and custom subject fields.

Example: N/A (same as subjects in Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx))

Rights Elements -- Discussed

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

...

  1. Custom
  2. 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.
  3. Existing custom subject fields will be consolidated to the dcterms:subject (dc.subject.none) element.

The only complication with this is shared with language.  We would like to change the name of a field without changing the contents and we don't have as nice a way to reexport subjects from IRIS/AT and then reimport to Dome, replacing the current subject fields.  Carl says if we are already doing this for names and dates, especially since we'll probably have to do this for every record it will not add much effort or complexity to throw this field and the language field in with the rexport/reimport.

Type Elements

  1. We will identify the one vocabulary that we will use for the DOME Core type field.  This vocabulary will be mapped to dcterms:type (dc.type.none).
  2. When a type vocabulary is defined within a specificaiton (for example, VRA Core type), we will use the identified field within that schema.  We will add the schema and field to the Dome metadata registry.
  3. 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 (current prefix: custommd).
  1. rights.copyright will be mapped dcterms:rights (dc.rights.none).

We will need to adjust our rights metadata requirement in the MIT Libraries Dome Collections DomeCore Metadata Element Set.  It should read, follow the guidelines in the Flickr Team Report and Recommendations (current version 05 May 2011).

Our approach to enforcing Rule2 will be similar to the custom identifier fields, custom relation fields, dc.language.iso, and custom subject fields.

Example: N/A (same as subjects in Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx))

Subject Elements -- Discussed

  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.

The only complication with this is shared with language.  We would like to change the name of a field without changing the contents and we don't have as nice a way to reexport subjects from IRIS/AT and then reimport to Dome, replacing the current subject fields.  Carl says if we are already doing this for names and dates, especially since we'll probably have to do this for every record it will not add much effort or complexity to throw this field and the dc.language.iso, the custom identifer fields, dc.rights.copyright, dc.relation.ispartofseries, and dc.relation.uri fields in with the rexport/reimport.

Example: http://dome.mit.edu.ezproxyberklee.flo.org/handle/1721.3/18867Image Added (see DomeMetadata_ex1.xlsx)

Type Elements -- Discussed

  1. We will identify the one vocabulary that we will use for the Dome Core type field (we choose DCMI Type Vocabulary).  This vocabulary will be mapped to dcterms:type (dc.type.none).
  2. When a type vocabulary is defined within a specificaiton (for example, VRA Core type), we will use the identified field within that schema.  We will add the schema and field to the Dome metadata registry.
  3. 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 (current prefix: custommd).

Currently type values from all vocabularies are entered in a dc.type.none element. Separating the values by vocabulary from existing Dome records will be tricky.  It would have to be done collection by collection.

For the Visual Collections community all values in the type filed are VRA worktypes.

For the archives collections most values in the type field are MODS Type Values.

It looks like the workflow for updating the existing type values will be:

1) Move existing values from dc.type.none to another appropriate element (either from another schema/vocabulary, or to a custom type element)

2) Add a DCMI type vocabulary value to the record.

Example: (Mikki will provide)Currently type values from all vocabularies are entered in a dc.type.none element. Separating the values by vocabulary from existing Dome records will be tricky.

Metadata Manipulation Notes

...

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