Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

  • Qualified Dublin Core registry in DSpace has not been updated for 8 years. Standardization would help compatibility with other systems and benefit from information gathered by the DCMI community (related links: https://jira.duraspace.org/browse/DS-805 https://jira.duraspace.org/browse/DS-433).
  • need consensus/guidance from metadata experts in the community on specifically how/what to update and which version of the DCMI standard should be used
  • need to link to the relevant schema on DC website and lock down (allow adds, but not changes)
  • isolate where local customizations are done  
  • https://wiki.duraspace.org/display/cmtygp/NewDublinCore Initial look at the requirements

2) Standardizing the default namespaces

...

  • Currently instead of creating a customized metadata schema, some DSpace repository managers edit the default registry, effectively breaking compliance with the standard Dublin Core. This can create a problem for the portability of data to/from of your repository. It has been proposed that in the future that DSpace would include 3 different metadata schemas, to insure that the metadata will be easily portable to other systems: 
    • 1) standardized default Dublin Core, un-editable (no changing or deleting fields) except to add fields with qualifiers to existing elements
    • 2) a yet-to-be developed DSpace admin/internal metadata fields that describe DSpace specific fields
    • 3) an empty local, easily customizable schema
  • need to validate the above strategy and confirm that if it was implemented it would prohibit changes and deletions that would break compliance with the standardized default Dublin Core metadata schema
  • ?Citation metadata?: perhaps use a subset of PRISM for citation metadata include it as a new namespace IS THIS THE RIGHT CATEGORIZATION FOR THIS OR SHOULD IT GO UNDER #5?

3) Adding metadata authority controls/vocabularies to the data model

...

  • depends on what schema (XML based schemas are more complex - dspace doesn't support XML - MODS,
  • MODS implemenation better done after fedora intergration since it is XML
  • need metadata expert
  • Hierarchal metadata:
    • add functionality / move towards relational aspect functionality - like MODS
    • allow relationships between community/collection/bitstream metadata
    • possible iterative solution - create functionality that emulates hierarchal behavior
    • example: adding in author affiliation
    • example: metadata on bitstream - related back to items
  • ?Citation metadata?: perhaps use a subset of PRISM for citation metadata include it as a new namespace IS THIS THE RIGHT CATEGORIZATION FOR THIS OR SHOULD IT GO UNDER #2?

6) Improved (or more transparent) flexibility:

...