...
- 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:
...