Proposal to Update QDC Registry and Add DCTERMS Registry

Recommendations towards “Updating the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI,” a priority identified in the October 2011 community survey on improving metadata support. It also seeks to comply with the proposal to Standardize the Default Namespace. 

Recommendation (tentative, pending further community input):

-Update current “DCMI Terms” metadata registry to QDC

-Add DCTERMS as new, parallel metadata registry

-Lockdown registries, offering migratory tools to pull out local customizations and push into new local schema. Make it possible but not easy to delete or edit elements in QDC and DCTERMS registries. Continue to enable the addition of qualifiers in the QDC registry

Main goal of these recommendations:

-Take steps toward ultimate goal of full compliance with DCTERMS, thus ensuring compliance with current standards endorsed by DC and linked data capabilities. By bringing the existing “DCMI” registry into QDC compliance, we also provide an intermediate migration step, enabling repositories to meet compliance with QDC upon upgrade, which will ease the transition to DCTERMS.

-By locking down registries, ensure compliance with QDC and DCTERMS standards but provide tools to allow customizations not compliant with QDC/DCTERMS to persist in local schema.

 Outstanding issues for committers and community:

-Is it possible to ultimately implement DCTERMS with full functionality? What changes to the data model will be necessary?

-If both QDC and DCTERMS are included, which will be considered the default? Is this projected to change?

-How will this proposal integrate with other suggested changes to DSpace metadata, including Proposal for Metadata Enhancement? How might it affect integration with Fedora? How might it affect other desired changes to metadata in DSpace, including implementing functional structured metadata such as MODS, METS, and PREMIS?

-What challenges will this proposal present—or solve—for harvesting?

-To enable repositories to migrate existing metadata to QDC and DCTERMS registries, we will need to develop robust tools for repositories to deploy. One outstanding issue is the design and development of these tools.  

Relevant JIRA tickets:

Areas/processes that will be affected by registry update:

-What areas and processes will be affected by these shifts? Is there any documentation of what features in DSpace are making use of certain fields? Where will the code be affected? Where are metadata elements hardcoded?

(pulled from September 4, 2012, DCAT discussion)

• Any processes that create new metadata in DSpace:
  
  • submission forms
  • spreadsheet importer
  • command line import
  • SWORD
  • built-in OAI Harvester

• Any process that displays metadata in the web used interface:
  
  • item pages
  • search, browse, DSpace discovery

• Any process that delivers the metadata (potentially via crosswalks) to other applications:
  • OAI server
  • REST API