Dome Metadata Update

12 March 2012

Genre/Type:
- We will use:
  - dc.type (DCMI Vocabulary Only)
  - dc.type.genre (use controlled vocabulary AAT, C&U, LSCH) [used by Texas]
  - vra.worktype (use controlled vocabulary AAT)

Note: we acknowledge that worktype and genre are very similar elements. Vra.worktype is an important key element for the cataloging of visual resources in SCS.

Index:
- Option 1: Index together
- Option 2: Index genre & worktype together, leave dc.type as a separately indexed field
- Option 3: all separate
Legacy Project:
- Option 1: Re-map as necessary?
- Option 2: Only worry about going forward and index will take care of any search/browse issues?
Rights: Currently using:
dc.rights.access (use statement)
dc.rights.copyright (copyright statement)
dc.rights (use & copyright)

Note: we feel that (if we continue to use qualifiers) "use" is a more accurate qualifier than "access", but also acknowledge that it is probably not worth the effort needed to change over. We should define "access" very broadly.

Note: "use" is not an official dc qualifier. - may be another reason to stick with "access" or just rights.

DC definition of accessRights: Information about who can access the resource or an indication of its security status. Access Rights may include information regarding access or restrictions based on privacy, security, or other policies.
*Options:

- Continue to use rights.access & rights.copyright (avoid using just rights)
- Use only rights (no qualifier) - can concatenate or use separate rights fields for various data

Note: data elements would still be separate in the management systems - but combined in the access/discovery system

Switch rights.access to rights.use (more accurate & more work). Use rights.use & rights. Copyright (avoid using just rights)
Other DC rights:
- rightsHolder: A person or organization owning or managing rights over the resource. (to support the identification of rights holders, either default copyright holders or a person or organization that is leagally empowered to assign and transfer licenses to the relevant resource)
- License: A legal document giving official permission to do something with the resource. (to support the identification of formal licenses associated with resources)
Local Identifiers (other than the official unique identifier)
- Additional identifier fields may be needed for local use, such as call number, vendor code, etc. We will continue to use qualifiers. New qualifiers will need to be vetted by the metadata group before being used. The current list of acceptable qualifiers is:
dc.identifier.vendorcode

dc.identifier.callnumber

No local metadata registry
- We had proposed creating a new registry for local needs. This was to include namesDisplay, datesDisplay, local identifier, local type and repository

- Based on our decisions to continue using dc for identifiers, types, and repository we will not create a registry for only the two display elements. However, we still believe that it is important to have both the name and date display fields in order to provide more information to our users

What will we use:
- Option 1: dc.date.display & dc.contributor.display
- Option 2: dc.descrption.names & dc.description.dates
Format:
- We will use:
  - vra.material (for dc.format.medium & dc.format.support
  - dc.format.???
- Index:
  - Include vra.material and dc.format.none or .medium in same index
- Legacy Project:
  - Option 1: use vra.material going forward (index could take care of search/display issues)

Note: this is a change from what we discussed yesterday. There is no dc.format.material. I think we talked ourselves in circles and combined dc.format.medium and vra.material. It would just be too easy for their to be a dc.format.material. (though we could create one if we really want to)
Example: http://dspace.sunyconnect.suny.edu/handle/1951/25937?show=full
DC definition of Medium: The material or physical carrier of the resource.

Elements to be discussed at a future meeting:

Repository/Custodianship :
- Other Institutions:
  - OhioLink: dc.publisher.Olrepository (also use - not officially - dc.contributor.repository and dc.repository.place)
  - Mountain West Digital Library: dcterms:publisher (Name of the entity that created or is providing access to the resource. Recommend clarifying the role this entity played in making the resource
    available by adding a prefix such as Digitized by, Hosted by, or Published by. For example, Published by Utah State Historical Society; digitized by Merrill‐Cazier Library, Utah State University; hosted by J. Willard Marriott Library, University of Utah.)
  - Rice: publisher (digital version published by…)
  - Ohio Wesleyan University: dc.repository.name
  - North Carolina ECHO: dc.publisher (the institution that published the digital resource and/or the institution that is hosting the digital resource)
  - DigitalGeorgetown: not used
  - Wright State University: dc.contributor.repository and dc.repository.place (ohiolink contributor)
  - Xavier University: dc.contributor.institution (XU); dc.publisher.digital (XU); dc.repository.name (digital Space @ X)
  - Ball State: dc.source
  - Georgia Tech: dc.publisher
  - CDL: Publisher

Dates:
- Need a way to use "undated"
- Will this work in date.created?
- Should we be using date.issued and just date.none (instead of created?)
- Can we concatenate coverage.spatial into the date.display field
- A date associated with an event in the life cycle of the resource. (Georgia Tech)
  - Rice: date.original - Date taken from source document. Text field that can contain a note to clarify dates - approximately, circa, etc.
Source
Citation
- Do we want to require a specific form of citation? Or leave citation format up to the collection administrators (MSM leaning toward the later)
- Consider putting a citation format on the collection page instead of at the item level?
have a page with our preferred citations – and a link from the item to that page?

3 January 2012

Access Rights
- Mods?

- Marc - is one copyright and one access?

Citation-
- Do we want to require a specific form of citation? Or leave citation format up to the collection administrators (MSM leaning toward the later)
- Consider putting a citation format on the collection page instead of at the item level?
- or have a page with our preferred citations – and a link from the item to that page?

Creator -
- Ohio Link - dc.creator is not used due to current dspace system specific limitations

Dates -
- Do we want to use a date.digitized? YES

Extent
- BP - May refer to the physical or digital manifestation of the resource

- BP- all extents should be put into one field?

Format-
- Should we have a dc.format and a vra.?

- No longer use dc.format.medium will now use vra.material

- Probably no dc.format from RVC - will use vra.technique

Identifier -
- dc.identifier.none

Language -
- Do we require a language code?

Local/Specific Type (VRA worktype?)
- What to do?

Publisher -
- LCNAF?

15 November 2011

Carl, Jolene, Mikki (preparing for Dome upgrade to DSpace 1.8)

To Do:

8 weeks to Dome upgrade

Mapping from Iris to DC Jolene
Mapping from AT to DC Mikki
Mapping from pre-existing Dome to new (legacy)
TEST in Dome test Carl
Set up new registries in Dome Mikki

Ongoing

guidelines for adding new registries
Dublin Core application profile (incorporate mot usage notes) Mikki

Questions

1. name for "customMD"
2. will custom display fields be used in the new display (beverly)
3. Can any registry be used for browse index? (Yes)
4. XML bitstream (table for now)

7 November 2011

Next Steps:
1. Mikki will take the first pass at pulling together a DC application profile from our notes.

11 October 2011

Metadata Operations Team – Dome metadata update project overview

To date there are eleven collections in Dome with a total of 63,784 items. As each collection was mapped into Dome, ad hoc decisions were made as to which metadata fields to use, what custom qualifiers to attach, and how these fields would be used within the scope of the collection. As the number of items and diversity of collections have grown, this has led to collections that are not always compatible with one another. An urgent need to update the metadata registry in Dome and establish sound metadata policies becomes more and more apparent with each new collection deposited in Dome.

Proposed updates to Dome metadata

Standardize use of metadata in Dome (in process of drafting an application profile https://wikis.mit.edu/confluence/display/LIBMETADATA/DOMEMDRULES|confluence/display/LIBMETADATA/DOMEMDRULES|||||\)
Create new metadata registries (if necessary to meet the needs of specific collections, formats and genres)
- All new schema must meet specific criteria and be approved by MOT prior to being added to the registry
Require all new items ingested into Dome meet these new standards
Remapped existing Dome records to comply with the new standards

Potential benefits

Shared vocabulary, definitions and metadata usage across all Dome collections
Improve browse and search capabilities across collections
Ability to manage format specific metadata
Better positioned for future projects involving data migration, manipulation and visualization

Next Steps

Dome Core (required and optional metadata) – approved by MCG 17 Aug 2010
Analyzed the current use of metadata elements in Dome and established definitions and usages parameters for Dome Core elements (both required and optional)
Draft a list of changes necessary to bring existing metadata in Dome into compliance with the Dome Core and the recommended registry changes
Create new metadata registries in Dome
- vra, and other schemas as necessary to meet the needs of specific formats and genres (pbcore, mods, etc.)
- custommd/dometerms (name up for debate)
  - new schema and namespace for local terms that do not fit into a standard recognized schema
Take action in each contributing community to bring workflows into compliance with Dome Core Metadata Policies
Determine what needs to be done to bring existing Dome records into compliance with new policies

30 March 2011

Prepared by the Metadata Operations Team (Jolene de Verges, Mikki Simon Macdonald, and Rob Wolfe)

for the Metadata Coordinating Group (Nina Davis-Millis, Tom Rosko, and Deb Morley)

The MIT Libraries have set up a repository for their growing collection of digitized content. This repository, named “Dome,” is an instance of the DSpace software package. The DSpace software comes with a default registry of metadata fields that has so far been only minimally adjusted as the Libraries have begun to deposit collections in Dome.

To date there are eleven collections in Dome with a total of 53,784 items. As each collection was mapped into Dome, ad hoc decisions were made as to which metadata fields to use, what custom qualifiers to attach, and how these fields would be used within the scope of the collection. This has led to collections that are not always compatible with one another. An urgent need to improve the metadata registry in Dome and establish sound metadata policies becomes more and more apparent with each new collection deposited in Dome.

The default registry of metadata fields in Dome is inadequate for the following reasons:

The metadata fields are modeled after the dublin core standard, but they do not strictly conform to the standard. They contain many custom elements that “qualify” the standard dublin core terms.

The metadata fields are geared towards scholarly publications and are not adequate to describe other types of material. So far text, images and complex content has be deposited in Dome, straining the descriptive capabilities of Dome’s metadata fields to their limit. Dome will soon contain audio, video, websites, archived internet content, rich media applications, maps and datasets.

Sound metadata policies are needed for the following reasons:

Dome collections will originate from many different sources each with unique metadata policies and practices. They will likely be cataloged prior to deposit in Dome and according to a variety of different metadata standards and schemas. This heterogeneous metadata needs to be reconciled to achieve consistent description of content in Dome.

Browse and search functions in the current Dome user interface require consistent use of each metadata field across all collections.
This consistent use of metadata is especially necessary in order to build new user interfaces on top of Dome that include all collections.
Established metadata requirements and policies allows future digitization projects to plan to meet them, eliminating the need to create an individual, idiosyncratic metadata mapping and workflow for each new collection we deposit in Dome.

In order to provide better access to our digital collections, we propose updating Dome (in accordance with newly drafted DomeCore metadata policy) to meet the changing needs of our collections and those of our user community.

Proposed updates to Dome (and Dome metadata)

Standardize use of metadata in Dome
Create new metadata registries, as needed (see Next Steps section for more details)
- this will mean that one item record may be comprised of elements from several different metadata schemas – this is already being done in DSpace in the OA and OCW collections
Require all new items ingested into Dome meet these new standards
Existing item records must be remapped to comply with the new standards