...

• 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. (Also consider a DSpace admin/internal metadata schema (not DIM)).
• 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 (search/browse, import/export, crosswalks, hard-coded 'dc' elements/qualifiers, etc.). Resolve issues with features that rely on metadata solutions (i.e., CC). Consider plugins, add-ons, interfaces, etc. as well.
• Lock down the "dc" and "dcterms" schema from the UI (at least at the element level for 'dc').
• Provide tools for current DSpace repositories to migrate to these schemas (i.e. edit their metadata registry and data), if desirable (i.e. Provide 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).
• "dcterms" is changed to default schema.
• Map out relationships between the four schemas.
• Address all areas of code affected (search/browse, import/export, crosswalks, etc.). Consider features, 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.

...

• 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.  
• Should DSpace admin/internal metadata (not including DIM) have its own schema, or use 'local' schema?

Recommendation background

...