...

• Update current “DCMI Terms” metadata registry to QDC
  
  • provide brief definition and reference (link?) for "DCMI Terms" and "QDC"
  • "DCMI Terms" is the name of the metadata registry that ships with DSpace. It was designed to comply with the draft Library Application Profile for Dublin Core, modeled on the flat, extensible Qualified Dublin Core standard. Soon after, the Dublin Core Metadata Initiative (DCMI) updated its Qualified Dublin Core (QDC) standard. 
  • provide reasoning - why is compliance with QDC (ultimately DCTERMS) important/desirable
  • Updating QDC to the latest standard of DCMI and Standardizing the default namespaces were identified as priorities in the October 2011 community survey on improving metadata support authored by DCAT at the request of the DSpace Committers/Developers. These updates were seen as standardizations that "would help compatibility with other systems and benefit from information gathered by the DCMI community" and would address the problem of broken compliance with the standard Dublin Core, which had affected portability to/from a repository.
  • provide a few specific examples of what fields would change from/to, perhaps identify some of what the basic differences would be from current DCMI
  • Updates range from the very basic (change dc.identifier.citation to dc.identifier.bibliographicCitation; dc.description.provenance to dc.provenance; dc.date.copyright to dc.date.copyrighted) to the addition of QDC elements like dc.accrualMethod and dc.audience. If we are continuing to allow qualifiers to be added to QDC elements in the registry, we may also continue to support the current qualified elements that are not specifically compliant with QDC (e.g., dc.contributor.editor). A preliminary mapping can be found here: https://wiki.duraspace.org/download/attachments/32478705/DCAT+QDC+preliminary+%28posted+to+DCAT+8.15.2012%29.xlsx  
• Add DCTERMS as new, parallel metadata registry
  
  • provide brief definition and reference (link?) for "DCTERMS"
  • DCMI has not updated its Qualified Dublin Core standard since 2005. The community standard has shifted towards DCMI Metadata Terms, which, unlike QDC, is not a flat schema based on the schema.element.qualifier format. DCTERMS include range and domain values. A particular term may link to another term that it refines or is refined by (for example: the dcterm "hasPart" refines "relation"; "created" refines "date").
  • provide reasoning - why is compliance DCTERMS important/desirable
  • DCTERMS is the currently maintained DCMI standard. As Sarah Shreeves recently commented:
    

    • "I want to strongly urge the group to look at conforming with DCMI terms (http://dublincore.org/documents/dcmi-terms/) - even if we can't conform to the vocabulary, etc, this is the most up to date and current form of the namespace. If we use the dc qualifiers document we will be perpetuating the same problem, IMO. I think we can, as Tim suggests, have a graceful path forward. I will admit that a real part of my fear of just moving to DC Qualified is that DSpace--in terms of metadata--will continue to be seen as out of touch with where much of the metadata world is headed."

  • provide a few specific examples of what fields would change from/to, perhaps identify some of what the basic differences would be from current DCMI
  • The ultimate goal, as described below, is to implement full compliance with DCTERMS, which would involve supporting the standard's range and domain values. This goal, however, is not possible with the current DSpace data model. For now, DCTERMS could be provided as a flat registry. Unlike our proposal for the QDC registry, the DCTERMS registry will not be an update of what currently ships with DSpace but a whole new set of elements. Some of these terms, however, are easily mapped between the existing "DCMI Terms" registry. For example, dc.date.created maps to dcterms:created. dc.format maps to dcterms:format. dc.date.updated maps to dcterms:modified. 
  • Some of these mappings remain to be decided and finalized. For example, DCTERMS provides a controlled list of syntax and vocabulary encoding schemes. QDC and "DCMI Terms" have often designated vocabulary and syntax encoding specifications as qualifiers (e.g., dc.subject.mesh, dc.identifier.uri). If we flatted DCTERMS, do we similarly extend with qualifiers (e.g., dcterms:subject.mesh)?  
    
  • A preliminary mapping can be found here: https://wiki.duraspace.org/download/attachments/32478705/DCAT+QDC+preliminary+%28posted+to+DCAT+8.15.2012%29.xlsx
    
• 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
• Clarify end result - how many metadata registries DSpace will ship with – 3?: 
  
  • 1) QDC - which will be an up date of the current DCMI, and will set as the default metadata schema 
  • 2) DCTERMS - which will be an optional metadata schema, ultimate goal of replacing QDC at some point in the future
  • 3) Local schema - which would ship empty, for the purpose of local customizations
  • Yes, the idea is for DSpace to ship with three metadata registries, to support ultimate migration to DCTERMS, allow for the continuing use of QDC, and standardize namespaces by pushing local customizations not compliant with QDC or DCTERMS into a local registry.
    

Main goal of these recommendations:

...