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.
Survey Result Highlights
* 84% of respondents use DSpace or plan to use DSpace
* 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 support ingest and export for the following standards Top 5 metadata schemas to include in DSpace, in order of priority: Dublin Dublin Core, MODS, PREMIS, Open URL ContextObject, ETD-MS
* 72% of respondents indicated it is a priority to add metadata authority controls/vocabularies to the data model
* 62% it of respondents indicated it is a priority to have enhanced metadata for Communities, Collections and/or individual Files (bitstreams)
* 56% it of respondents indicated it is a priority to update to update the Qualified Dublin Core registry to the lastest latest standards of the DCMI.
* 54% would of respondents indicated would not have objections to prohibiting changes/deletions that would break compliance with the standardized default Dublin Core metadata schema
The 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 1000 1,000 organizations for a reason – it is relatively easy to get a repository up and running. If we are to add more complexity/flexibility to DSpace 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. In addition, there are existing software solutions that provide for the ultimate in flexibility, namely Fedora. 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 and locking it down (allow adds, but not changes or deletions that would break compliance) as well as isolating where customizations are done to ensure better standardization , adopting the newer DC Terms namespace (http://dublincore.org/documents/dcmi-terms/ ) as an evolutionary step over 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 would be prevented from modifying the standardized DC metadata which would effectively break compliance. Instead, local modifications would be accomplished in a separate metadata schema.
3) Enhanced 3) Enhancing 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) Improvements in the UI - simplifying where/how things are done and bring more functionality to the UI, some examples include:
- import/export to metadata other than DC (like in Eprints where you pick a format for export)
- local customization
- how to plug in metadata schemas
- expose RDF triples
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
Simplify and make local customizations more accessible by bringing more functionality into the user interface or metadata registry. This could also include a utility to import/export metadata to a schema other than DC. 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 metadata is not stored in the 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.
How can you help?
If any of the above priorities are important to you or your organization, we need your help. In order to move forward we plan to put together a project team from the user community for each priority. If there are no volunteers, there will likely be no meaningful movement forward. Please contact Valorie Hollister at vhollister@duraspace.org in you are interested in contributing your time and effort.- 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