You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

At the request of the DSpace Committers and Developers, the 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

* Aside from a vast majority (*include figure) who indicated that Dublin Core was the most relevant standard to them, there were needs to support ingest and export for following standards, in order of priority: 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

* 62% of respondents indicated it is a priority to have enhanced metadata for Communities, Collections and/or individual Files (bitstreams)

* 56% of respondents indicated it is a priority to update to update the Qualified Dublin Core registry to the latest standards of the DCMI.

* 54% of respondents indicated would not have objections to prohibiting changes/deletions that would break compliance with the standardized default Dublin Core metadata schema

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 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 metadata authority controls/vocabularies to the data model: Since there is an existing add-on for controlled vocabularies (INSERT LINK), DCAT interprets this to mean that the rights to use a controlled vocabulary and possibly link 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 the Qualified Dublin Core registry to the current DCMI standards, adopting the newer DC Terms namespace (as an evolutionary step over the 15 original elements in the dc namespace). 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 the standardized DC metadata that will effectively break compliance. Therefor, putting those modifications in a separate metadata schema will lower the risk of breaking compliance.

3)   Enhancing the metadata available for Community, Collections and Files (bitstreams)

4)   Simplify/make local customizations more accessible though user interface

- simplifying where/how things are done and bring more functionality to the user interface or 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 

  

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

- 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

  • No labels