...
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
...
Note: We need to discuss the use of birth and death dates in the contributor field that is intended to contain only a contributor's name. These dates may be useful to distinguish between contributors that share a name. They may also be included in LC NAF versions of names. We think that the MIT Libraries are moving towards asserting LC NAF control over names in DSpace/Dome. We should also consider using dates when they are used in other authority files (for example, ULAN Getty Union List of Artist Names).
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.
Date Elements - Discussed
- dcterms:created (dc.date.created) will be used for the creation date of non-published Items., publication, or origination date of all Items. If an Item has multiple origination dates (created, modified, published, etc.), it is up to the collection administrator to identify the primary origination date for this field and put all others in dcterms:date (dc.date.none).
- Either dcterms:issued or dcterms:created must be present in an Item's metadata to satisfy the Dome Core MD Requirement.
- When describing the coverage of an Item (the date as the subject) use dcterms:temporal (dc.coverage.temporal).
- dcterms:datecopyrighted (dc.date.copyright) will be used for Items with different copyright and publication dates.
- dcterms:available (dc.date.available) will be used for embargoed Items.
- dcterms:accesioned (dc.date.accessioned) will only be used by the DSpace system.
- dcterms:issued (dc.date.issued) will only be used by the DSpace system.
- dcterms:date (dc.date.none) will be used for all other dates. It may be repeated for multiple dates.
- A new element will be added to the Dome metadata registry (dome:dates(?)datesDisplay). 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.
- 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. Put other dates in dcterms:date or in dcterms:temporal. dcterms:created or dcterms:issued . Put other dates in dcterms:date or in dcterms:temporal.should be reserved for the date or origin of the object and dcterms:temporal for the date of the subject matter of the object. If we just use dcterms:created for all orgin dates, collections would be free to choose the most significant date associated with the origination of the object. All other dates should go into dcterms:date.
- dcterms:temporal and dome:datesDisplay will have no enforcement of date format. We will enforce a consistent format for dcterms:created and dcterms:date. We should consider ISO 8601 or Fuzzy Dates (need to find a standard or authority for Fuzzy Dates). Both can handle ranges and other kinds of complex date statements.
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?
Carl's Comments
1. Current DSpace system functionality is as follows: If an issue date is provided upon ingest it is put in dc.date.issued. If one is not provided, DSpace will put the date of deposit in the dc.date.issued field. The question is can we change DSpace to not automatically populate this field.
An alternative is to put both a publication or a creation date in to dc.date.created, ignoring the distinction between formally published and informally distributed items. This would allow DSpace to do it's own thing with dc.date.issued. We would then ignore dc.date.issued for browse and search indices. WE ELECTED TO ADOPT THIS ALTERNATIVE. ALL ORIGINATION (CREATION OR ISSUANCE) DATES WILL BE PUT INTO DCTERMS:CREATED AND DCTERMS:ISSUED WILL BE LEFT TO THE DSPACE SYSTEM TO POPULATE AUTOMATICALLY WITH THE DATE OF DEPOSIT.
2. Question for Richard: If we format our dates to conform to ISO 8601 how will that affect how DSpace indexes these dates for searching and browsing? Will it be able to parse these dates to present them in a meaningful way in a search or browse index?
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.
Notes Elements - Discussed
- Use dcterms:abstract (dc.description.abstract) for formal abstracts.
- Use dcterms:tableOfContents (dc.description.tableofcontents) for formal tables of contents.
- Use dcterms:description (dc.description.none) for all other notes or descriptions.
- At least one of the above three elements are required to satisfy the Dome Core MD Requirement.
- 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
- dc.description.sponsorship -- Has been used once (We should just move this by hand).
- dc.description.provenance -- Has been used (This is the provenance statement, we will let DSpace use this as it pleases).
- dc.description.statementofresponsibility -- Not been used
- dc.description.uri -- Not been used
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.
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
Language Elements - Discussed
- dc.language.iso will no longer be used in Dome.
- Existing dc.language.iso fields will be mapped to dcterms:language (dc.language.none).
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
Rights Elements
- dc.rights.uri will no longer be used in Dome (there are currently no populated dc.right.uri fields).
Subject Elements -- Discussed
- 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.
- 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
Metadata Manipulation Notes
...