The priorities below are based on the October 2011 community survey on improving metadata support. DCAT has interpreted the community priorities based on the survey results and have fleshed out those priorities with detailed descriptions, specifics and examples. Anyone should feel free to add their feedback as we will eventually evolve this page into a project plans.
Improved (or more transparent) flexibility:
- simplify/make local customizations more accessible through UI:
- simplify where/how things are done - bring more functionality to the UI or the metadata registry
- create more educational/tutorials on how/where to do things (i.e. how to plug in metadata schemas)
- import/export to metadata other than DC (like in Eprints where you pick a format for export)
- expose RDF triples
Update the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI
- link to the relevant schema on DC website and lock down (allow adds, but not changes)
- isolate where local customizations are done
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
Add metadata authority controls/vocabularies
- education/tutorials on current add-on
- open up rights to use a controlled vocal and link from an external source so it doesn't have to be brought into DSpace - update problem
- example: Nat'l Agricultural Library - linked open data, LC, subject based, NLM
Citation metadata
- perhaps use a subset of PRISM for citation metadata include it as a new namespace
Enhanced metadata for Communities, Collections and/or individual Files (bitstreams)
SURVEY
The priorities below are based on the fall 2011 community survey. They are listed in the order of how much community effort will be required, starting with relatively small amount of time/effort and moving on to more complex/time consuming projects.
1) Updating the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI
- LEVEL OF COMMUNITY EFFORT: likely small to medium effort
- LEVEL OF DEVELOPER EFFORT: likely small to medium effort
- need consensus/guidance from metadata experts in the community on what specifically needs to be fixed, which version of the DCMI standard should be used
2) Standardizing the default namespaces
- LEVEL OF COMMUNITY EFFORT: likely small to medium effort
- LEVEL OF DEVELOPER EFFORT: likely small to medium effort
3) Adding metadata authority controls/vocabularies to the data model
- LEVEL OF COMMUNITY EFFORT: likely medium to high effort
- LEVEL OF DEVELOPER EFFORT: likely medium to high effort
- authority controls exist already, need to identify what specifically the community is lacking -- or is this more a training/educational task?
- not allowed to ship DSpace w/Library of Congress headings
- need to identify what the community thinks will work better in order to determine how big the problem is
4) Moving metadata related configurations from dspace.cfg to the database
- LEVEL OF COMMUNITY EFFORT: likely medium to high effort
- LEVEL OF DEVELOPER EFFORT: likely medium to high effort
5) Develop support for additional metadata standards (use the "Other" field to specify which standards)
- LEVEL OF COMMUNITY EFFORT: likely medium to high effort
- LEVEL OF DEVELOPER EFFORT: likely medium to high effort
- 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
5) Enhancing the metadata available for Communities, Collections and Files (bitstreams)
- LEVEL OF COMMUNITY EFFORT: likely high effort
- LEVEL OF DEVELOPER EFFORT: likely high effort
- get discussioin started and find some dev interested in archtecting it
- very large changes, every single object in DSpace, will present and upgrading challenging to convert to an entirely different object model could be preparation for integration with Fedora - re-factoring how best we can re-work dspace to support in the next few versions - not a quick jump
