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.

Title (Goal)Structure - Community and Collection hierarchy (or generic containers)
Primary ActorEnd User
Scope 
Level 
Story (A paragraph or two describing what happens)

User should be able to define alternative structure to repository. Issues identified:

  • Some users do not want to be forced to work with Communities and Collections.
  • Some users want "User Centric" or "User Controlled" Collections.
  • Some users want to upload content without selecting collection
  • Some Repository Managers want to be able to select Collection as part of Workflow

Having general defaults for Submission Process and Workflow that are independent of Collection will give user ability to ignore these options. Treating Submission and Workflow as "Containers" rather than "Activities in a Container" will allow for more flexible workflow processes.

2 Comments

  1. We agree that we should get rid of the restrictions on the structure of the data. These cause a headache for curators that we could do without i.e. that an item cannot be added into a community but has to be in a collection, which cannot be subdivided into collections. It would be better to create more flexibility by just having collections (instead of communities), but to allow sub-collections within collections (I think ‘Collection’ is a more user-friendly term than ‘Container’). This would be much easier for curators to learn, to document and to explain to depositors.

  2. This use case is loosely related to one story in Structure - Create / manage files and metadata (as an Item), in that both describe an idea of a more flexible content model / hierarchy.  This use case is about simplifying the Community / Collection hierarchy, while the other is more about the Item / Bitstream hierarchy