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 Actor||End User|
|Story (A paragraph or two describing what happens)|
User should be able to define alternative structure to repository. Issues identified:
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.
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.
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