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.
Work in Progress
May 2015: This is an active document. It is not finalized, and may change in the coming month as the DSpace RoadMap Working Group and Steering Group create a final draft for presentation at OR15.
This Technical RoadMap is based on the DSpace 2015-18 Strategic Plan - Technology and the Use Case Analysis produced by the DSpace RoadMap Working Group in April/May of 2015.
Candidate Features for DSpace 6.0
(NOTE: This list is incomplete, and does not represent a list of ALL features to be added into DSpace 6.0 in late 2015. It just notes a few smaller features / goals from the 2015-18 Strategic Plan for Technology which will be targeted towards the 6.0 release. Based on the tight timeline for 6.0, most major features/goals from the Strategic Plan for Technology are scheduled for the 7.0 release in late 2016.)
| Priority 1 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases |
|---|---|---|---|---|---|
| Single Search / Browse System (SOLR) |
| Goal 2: Lean and flexible | x | Low |
|
| Single built-in Statistical Engine (SOLR Statistics) |
| Goal 2: Lean and flexible | x | Low |
|
| NOTE: More features will be discussed on the DSpace Release 6.0 Status page, and added to this list as they are finalized. Work on the 6.0 release is proceeding in parallel to the development of this RoadMap, and therefore, this RoadMap primarily represents the goals/candidate features for the 7.0 release in 2016.) | |||||
Candidate Features for DSpace 7.0 - Priority 1
(NOTE: The DSpace 7.0 release is tentatively scheduled for late 2016 or early 2017. The below candidate features are ordered in terms of perceived importance to the 7.0 release. However, if you or your institution would like to drive or lead the development of a specific feature, you are welcome to volunteer your time towards any of the candidate features listed, no matter where that feature ranks in the listing.)
| Priority 1 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases |
|---|---|---|---|---|---|
| Single User Interface |
| Goal 2: Lean and flexible | x | High | For reference: |
| Configurations in Admin User Interface |
| Goal 5: Low cost, "just works" | x | High | |
| Easy and Intuitive Deposit Interface |
| Goal 1: Fundamentals of IR | x | Medium | |
| Non-functional: "Module" Framework and Registry |
| Goal 3: Can be "extended" | x | High | |
| Simplify Community & Collection Hierarchy | The concept of having two types of "containers" (both Community and Collection) does not seem to meet any modern IR need. It also complicates our content model, and forces DSpace users into a very specific hierarchy of content. We should replace this hierarchy with a single type of "container" (working title: Collection). This new type of "Collection" should be able to either contain Items or sub-Collections or both. This would allow Collections to replace Communities altogether.
| Goal 2: Lean and flexible | x | High |
Candidate Features for DSpace 7.0 - Priority 2
(NOTE: The DSpace 7.0 release is tentatively scheduled for late 2016 or early 2017. While these features are listed as "priority 2", if there is community interest in moving one or more of these features forward, that feature would be added as a priority for the 7.0 release.)
| Priority 2 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases |
|---|---|---|---|---|---|
| Hierarchical Metadata Support | DSpace should support hierarchical metadata formats (e.g. MODS) | Goal 1: Fundamentals of IR | x | High | |
| Relationships between Objects | DSpace should support defining relationships between objects (especially at the Item and Bitstream level). Some object relationships may be definable via metadata, but should be respected by the DSpace UI. But, in other situations, it may also necessitate the creation of new types of Objects (e.g. Author objects as Authors of an Item rather than simply textual metadata)
| Goal 1: Fundamentals of IR | x | High | |
| Enhance Basic Statistical Reporting |
| Goal 1: Fundamentals of IR | x | Medium |
|
| Enhance Basic Preservation |
| Goal 1: Fundamentals of IR | x | Medium |
Post-7.0 Features
(NOTE: While these features are scheduled as "post-7.0" at this time, we still encourage volunteers to begin to analyze or tackle them. If there is interest in moving one or more of these features forward in the nearterm, we can immediately move it up into the 7.0 release.)
| Priority 2 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases |
|---|---|---|---|---|---|
| Non-functional: Easier Installation |
| Goal 5: Low cost, "just works" | x | ||
| Non-functional: Easier Upgrade Process |
| Goal 5: Low cost, "just works" | x |
| |
| Advanced Usage Statistics |
| Goal 3: Can be "extended" | High |
| |
| Theme management in Admin UI |
| Goal 5: Low cost, "just works" | x |
| |
| Enhance Versioning |
| x | |||
| Replace "Bundle" object with Metadata or similar | A "Bundle" object is just a simple grouping of Files (Bitstreams) (e.g. "THUMBNAIL", "TEXT"). Rather than being its own object, a "bundle" could be more easily replaced with metadata on individual Bitstreams (e.g. dc.type="thumbnail"), or even relationships between Bitstreams (i.e. derivative objects).
| Goal 2: Lean and flexible | x | Medium | |
| Advanced Preservation |
| Goal 3: Can be "extended" | High | ||
| Enhance Search / Browse System |
| Goal 1: Fundamentals of IR | x | ||
| Enhance Access Control |
| Goal 1: Fundamentals of IR | x |
Overview
Content Tools
All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license
, unless otherwise noted.