Historical JIRA references: JIRA-433 and JIRA-805.
Description:
Our goal was to tackle the task of "Updating the Qualified Dublin Core registry in Dspace to the latest standards of the DCMI", in coordination with the goal of "Standardizing the Default Namespace." Given the incompatibility of the current DCMI terms standard (which necessitates implementing range and domain properties) with the DSpace data model, we are focusing on the more discrete task of evaluating elements in the current Dspace "DC" registry and adding or updating them to comply with DCMI QDC standards (themselves a loose set of standards). As a benefit, the updated QDC allows for a fairly direct mapping to the flat DCTERMS. This may ultimately allow for a neater migration to the DCTERMS.
Our first attempt to evaluate the task and make recommendations is attached as a xslx file. Further recommendations hinge on: the community's sense of the importance of locking down the DC registry (and the level of desired lockdown, i.e., at the element or qualifier level); input on the operational-to-DSpace nature of certain elements; and feedback on the desirability of moving closer to the DC terms standards currently recommended by DCMI.
Questions:
- We aimed to integrate our task with the goal of Standardizing the Default Namespace. Is it plausible, from a developer's perspective, to implement this task's "standardized default Dublin Core, un-editable (no changing or deleting fields) except to add fields with qualifiers to existing elements" in the metadata registry? Specifically, would it be possible to largely lock down the DC registry but allow additions to be made only to qualifiers (I.e., no one could add dc.personal.ddc, but they could add dc.subject.ddc)?
- Is there a clear preference for locking down the DC registry?
- Given that the DC terms data model is currently incompatible with DSpace, we aimed to update the QDC registry to the last version of DC that would also comply with the Dspace data model. Is anyone aware of a QDC document that supersedes this one: http://dublincore.org/documents/usageguide/qualifiers.shtml?
- Has any previous work been done to identify those Dspace-specific fields that should be migrated to a separate registry? (Mentioned here) This may help guide our decision to make the QDC registry more "pure DC" and shed the Dspace operational fields to another registry.
- For those more familiar with internationalization work: Dspace current ships with dc.language.rfc3066. Should we add or suggest migrating to dc.language.rfc5646? What would this change or suggestion entail?