Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This is a priority identified by the October 2011 community survey on improving metadata support authored by the DSpace Community Advisory Team at the request of the DSpace Committers/Developers. DCAT has summarized and interpreted the information gathered from the survey estimated level of effort required. DSpace community members should feel free to add more detailed explanation/examples to further flesh out the changes/requirements they would like to see. It is recommended that a community project team be formed around this work.   

Project Description

  • 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
  • This project should consider/coordinate with the Updating the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI project

Estimated Effort Level Required

LEVEL OF COMMUNITY EFFORT: likely low to medium
LEVEL OF DEVELOPER EFFORT: likely low to medium

Project Team

If you would like to participate or lead this project team, please identify yourself here and/or send a message to the dspace-tech mailing list. 

  • No labels

2 Comments

  1. Mark Diggory

    A few observations:

    Its only when "adding elements" that Qualified Dublin Core compliance is really broken.

    1. Dublin Core Elements "element" should not be editable
    2. The new Dublin Core Terms "element" should not be editable as well.
    3. However, As long as Qualifiers remain a feature of DSpace, they can be used/altered to endusers benefit

    The reason for 3 is that this is the only means to get new fields to map into OAI DC and QDC crosswalks. In this manner, the simplest solution is:

    • To not allow new elements to be added/changed in the User interface in any standard namespace (DC, DCTERMS, ...).  
    • Elements should be addable/editable in a "local" namespace.  
    • Converters that execute on upgrade should migrate any non-standard "elements" to local namespace.

  2. Sarah Potvin

    Just added: a proposal page that addresses some of the issues here: Proposal to Update QDC Registry and Add DCTERMS Registry

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.