Versions Compared

Old Version 7

changes.mady.by.user Mikki Simon Macdonald

Saved on

compared with

New Version Current

changes.mady.by.user Mikki Simon Macdonald

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

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)

...

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

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)

...

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

...