Page History
...
- DCMI
- Dublin Core Metadata Initiative http://dublincore.org/
- The Dublin Core Metadata Initiative (DCMI) manages the long term curation and development of DCMI specifications and metadata terms namespaces
- DCMI Metadata Terms
- http://dublincore.org/documents/dcmi-terms/
- Specification of all metadata terms maintained by the Dublin Core Metadata Initiative, including properties, vocabulary encoding schemes, syntax encoding schemes, and classes
- DCMES
- Dublin Core Metadata Element Set, Version 1.1 http://dublincore.org/documents/dces/
- DCTERMS
- Properties in the /terms/ namespace http://dublincore.org/documents/dcmi-terms/#H2
- DC
- 'Simple Dublin Core' (elements only, no qualifiers)
- Properties in the /elements/1.1/ namespace http://dublincore.org/documents/dcmi-terms/#H3
- The fifteen terms of the Dublin Core Metadata Element Set, which have also been published as IETF RFC 5013 [RFC5013], ANSI/NISO Standard Z39.85-2007 [NISOZ3985], and ISO Standard 15836:2009 [ISO15836]
- Schema name of the DSpace (up to 3.x) metadata registry default/shipped with schema (incorrectly referred to as dcmi-terms)
- QDC
- Elements with qualifiers
- Qualified Dublin Core (QDC)
...
- The ultimate goal of these recommendations is to implement fully functional DCTERMS as the default metadata schema, thus ensuring compliance with current standards endorsed by DCMI and linked data capabilities, and enabling a metadata infrastructure that supports other hierarchical and relational data structures.
- These recommendations also provide for intermediate steps towards this ultimate goal.
- By bringing the existing default 'dc' schema into compliance with the Qualified Dublin Core standard, we provide an intermediate migration step, enabling repositories to meet compliance with QDC upon upgrade, which will ease the transition to DCTERMS. (See "Possible Phases of Update," below, for further details about staging.)
- By locking down schemas (at least at the element level), we 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 schemas, we will need to develop robust tools for repositories to deploy. One outstanding issue is the design and development of these tools.
- Need help on how best to map between schemas - QDC vs. DCTERMS schemas and how they will work together.
Possible Phases of Update
Ultimate goal = 'dcterms' schema as metadata registry default schema
Phase One: Update current default 'dc' schema in metadata registry to latest qualified Dublin Core, add 'dcterms' and 'local' as parallel schemas in registry
- Update "dc" registry that ships with DSpace to current qualified Dublin Core (QDC) standard. In Phase One, name of default schema remains "dc".
- Current "dc" elements are migrated to updated "dc" registry (where compliant with that standard) or pushed to "local" registry
- Develop and implement flat "dcterms" schema
- Develop and implement "local" schema
- Ship DSpace with "dc," "dcterms," and "local" schemas in metadata registry ("dc" remains default schema).
Map out relationships between these three schemas
- Address all areas of code affected. Consider plugins, add-ons, interfaces, etc. as well.
- Provide tools for current DSpace repositories to migrate into these registries, if desirable (i.e. Provide tools for migrating "dc" elements not compliant with QDC to "local" registry.)
Phase Two: Plan for migration from "dc" to "dcterms" as default schema in DSpace metadata registry.
- Create "qdc" schema.
- Current default "dc" schema is pared down to just "dc" (the fifteen elements).
- "dcterms" is changed to default schema.
- Map out relationships between the four schemas
- Address all areas of code affected. Consider plugins, add-ons, interfaces, etc. as well.
- Provide tools for migration from DSpace "dc" (the qualified version) to new schemas
- DSpace ships with "dc," "qdc," dcterms," and "local"
Phase Three: Develop "dcterms" as fully functional default registry in DSpace, with range and domain values enabled and formally assigned.
- Address functional use of vocabularies and range and domain values.
- Potentially deprecate 'qdc'
...
Possible Phases of Update
Ultimate goal = 'dcterms' schema as metadata registry default schema
Phase One: Update current default 'dc' schema in metadata registry to latest qualified Dublin Core, add 'dcterms' and 'local' as parallel schemas in registry
- Update "dc" registry that ships with DSpace to current qualified Dublin Core (QDC) standard. In Phase One, name of default schema remains "dc".
- Current "dc" elements are migrated to updated "dc" registry (where compliant with that standard) or pushed to "local" registry
- Develop and implement flat "dcterms" schema
- Develop and implement "local" schema
- Ship DSpace with "dc," "dcterms," and "local" schemas in metadata registry ("dc" remains default schema).
Map out relationships between these three schemas
- Address all areas of code affected. Consider plugins, add-ons, interfaces, etc. as well.
- Lock down the "dc" and "dcterms" schema from the UI.
- Provide tools for current DSpace repositories to migrate into these registries, if desirable (i.e. Provide tools for migrating "dc" elements not compliant with QDC to "local" registry.)
Phase Two: Plan for migration from "dc" to "dcterms" as default schema in DSpace metadata registry.
- Create "qdc" schema (move the 'dc' that is QDC to 'qdc').
- Current default "dc" schema is pared down to just "dc" (the fifteen elements). The new 'dc' will follow the
- "dcterms" is changed to default schema.
- Map out relationships between the four schemas
- Address all areas of code affected. Consider plugins, add-ons, interfaces, etc. as well.
- Provide tools for migration from DSpace "dc" (the qualified version) to new schemas
- DSpace ships with "dc," "qdc," dcterms," and "local"
Phase Three: Develop "dcterms" as fully functional default registry in DSpace, with range and domain values enabled and formally assigned.
- Address functional use of vocabularies and range and domain values.
- Potentially deprecate 'qdc'.
Phase Four: Celebrate.
Outstanding issues for committers and community
- Is it possible to ultimately implement DCTERMS with full functionality (vocabularies, etc.)? 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 schemas, we will need to develop robust tools for repositories to deploy. One outstanding issue is the design and development of these tools.
- Need help on how best to map between schemas - QDC vs. DCTERMS schemas and how they will work together.
Recommendation (tentative, pending further community and committer input)
...
Overview
Content Tools