At the request of the DSpace Committers and Developers, the DSpace Community Advisory Team (https://wiki.duraspace.org/display/cmtygp/DSpace+Community+Advisory+Team
) (DCAT) has begun an effort to build a community consensus on improving the metadata support in future DSpace releases. Last month this process began with a community survey to collect feedback on what improvements organizations would like to see relative to metadata support in DSpace.
...
* 84% of respondents use DSpace or plan to use DSpace
* Aside from a vast majority (*include figure) who 86% of respondents indicated that Dublin Core was the most relevant metadata standard for their organization
* In addition to Dublin Core, respondents saw a need to them, there were needs to support ingest and export for the following standards, in order of priority: Dublin Dublin Core, MODS, PREMIS, Open URL ContextObject, ETD-MS (* removed "include" here because that's too vague**)
* 72% of respondents indicated it is a priority to add metadata authority controls/vocabularies to the data model
...
The complete survey results are available here: INSERT LINK
Where do we go from here?
From the survey it is clear that there are improvements to metadata support in DSpace that could help solve some common challenges for many organizations. Many will agree that there is no one size fits all repository software. DSpace is the most popular repository software, used by over 1,000 organizations for a reason – it is relatively easy to get a repository up and running. We need Because of this the DSpace developers have to be careful that adding functionality it is not at the cost of making it more difficult for the vast majority of DSpace use cases. With that in mind, DCAT has proposed exploring the following priorities with the DSpace Committers/Developers and the user community:
1) Adding Add metadata authority controls/vocabularies to the data model: Since . Since there is an existing add-on for controlled vocabularies (INSERT LINKhttps://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values), DCAT interprets this to mean that we should open up the rights to use a controlled vocabulary and possibly link it from an external source. Some examples would be the National Agricultural Library (linked open data) and the National Library of Medicine (subject based).
2) Updating Update the Qualified Dublin Core registry to the current DCMI standards, adopting the newer newer DC Terms namespace (http://dublincore.org/documents/dcmi-terms/ ) as an evolutionary step over the the 15 original elements (http://dublincore.org/documents/dces/) in the dc namespace). Based on the community survey, DCAT also recommends that the default configuration should separate out standardized DC metadata, administrative metadata and local customizations into distinct metadata schemas. Repository administrators should be at least informed and furthermore actively discouraged to apply modifications to would be prevented from modifying the standardized DC metadata that will which would effectively break compliance. ThereforInstead, putting those local modifications would be accomplished in a separate metadata schema will lower the risk of breaking compliance.
3) Enhancing Enhanced the metadata available for Community, Collections and Files (bitstreams). Unlike Items, Collections, Communities and Files (bitstreams) currently do not have Dublin Core metadata associated with them. The community has expressed an interest in making the available descriptions more granular.
4) Simplify /and make local customizations more accessible though user interface- simplifying where/how things are done and bring by bringing more functionality to into the user interface or metadata registry
- create more educational/tutorials on how/where to do things (i.e. how to plug in metadata schemas)
- . This could also include a utility to import/export metadata to metadata a schema other than DC (like in Eprints where you pick a format for export)
- expose RDF triples
. Some community members expressed an interest in exposing the RDF triples. In addition, DCAT recommends a comprehensive tutorial on how/where to perform specific metadata schema tasks be developed.
5) Explore the implications of offering hierarchal metadata in DSpace and whether it makes sense, given the DSpace/Fedora integration work. Hierarchal metadata would allow for relationships between community/collection/bitstream metadata. Because Fedora 5) Explore how to create hierarchal metadata - should be approached with great care. Any new work shouldn't contradict future plans or approaches to move DSpace closer to the Fedora model (in which metadata is not stored in the DB but rather in files).
- move away from flat DC which doesn't have relational aspects and towards relational aspect functionality - like MODS
database, as it is in DSpace, but in files, the relational aspect functionality in Fedora is more flexible. It is hoped that the DSpace/Fedora integration work would take advantage of Fedora's flexibility. DCAT proposes that the community explore the implications/reasonableness of a separate effort on hierarchal metadata in addition to the DSpace/Fedora integration.- allow relationships between community/collection/bitstream metadata
- possible iterative solution - create functionality that emulates hierarchal behavior
- example: adding in author affiliation or metadata on bitstream - related back to items