Metadata Team Agenda 12.19.13

Date

December 19, 2013

Attendees

• Sarah Potvin

• Unknown User (mpwalsh)

• Bram Luyten (Atmire)

• @Monica Rivero

Discussion Items/Notes

DSpace metadata not completely flat-- ability to use authority keys (part of 1.6 Authority Control feature). Can be used for LC Name Authority lookup. Also a place to store staff ID, ORCiD, etc. Currently useful as way to hover over value to see additional key or provide lookup. Also queryable when harvested. Integrated in submission form. For proper DCTERMS, would need to enforce use of that authority key for certain terms, and stored literal is more "eye candy" for display.

ContentDM based on DCTERMS? Or just Simple DC?

Application profile and ability to specify multiple schema-- DCTERMS alongside DC, local, thesis, etc.

Potential need to adopt RIOXX for SHARE: http://rioxx.net/v1-0/ Will need to be more attentive to funders and grant numbers even in absence of SHARE. Compliance-driven need.

Bram Luyten (Atmire) worked to ensure DSpace/RIOXX compliance. 

Will definitely need to maintain DC alongside DCTERMS. Question of whether to keep legacy qualified DC or to migrate to local. Ability to crosswalk dc.title to dcterms.title, not absolutely a requirement to migrate to that element in DSpace metadata.

Mission for DSpace 5: Death to the Qualifiers.

RIOXX using DCTERMS for what DSpace currently relies on QDC for; uses DC where DSpace uses DC. 

Potential of additional schema to ship with DSpace: RIOXX, ETD schema.

Next Steps

1) Highest priority is to examine qualified fields-- we will start migration with this set. 

Example: dc.contributor.advisor–> uketd:advisor ? Going beyond DC, DCTERMS, local, DSpace. Keeping an eye on developments around ETD and research data schema.

QDC list pulled from Full Draft mapping of QDC, DCTERMS, and local schema

For ongoing re-evaluation of QDC mappings, see Re-evaluation of QDC mappings

QDC currently in DSpace, with suggestions for mappings from DCAT Metadata Team members.

2) Have DSpace metadata proposal formalized for Open Repositories, deadline of February 1. Also Dublin Core 2014. 

3) Non-intrusive approach to modifying hard-coded metadata values via JIRA tickets

• Identify any hard coded occurrence of a field, make configurable, retain the same initial value. Will allow us to get rid of hard coding while still keeping everyone on same metadata schema for now
  • Example JIRA ticket:
    • "Remove hard coded references to dc.title"
    • Identify all hard coded occurrences of dc.title and replace them with values that can be stored and retrieved from dspace configuration files.