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 | Volunteers |
|---|
| Single Search / Browse System (SOLR) | - Lucene and old DB browse system are already deprecated. Just need removal
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | DS-2160 |
|---|
|
| 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 | Volunteers |
|---|
| Single User Interface | Design - Single UI Project | Goal 2: Lean and flexible | x | High | For reference: | | | Configurations in Admin User Interface | - Dependent on / related to "Single User Interface"
| Goal 5: Low cost, "just works" | x | High | | Expand |
|---|
| title | Configuration Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 30 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| labels | uc-configuration |
|---|
|
|
| | | Easy and Intuitive Deposit Interface | | Goal 1: Fundamentals of IR | x | Medium | | Expand |
|---|
| title | Other Deposit Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 20 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| labels | uc-deposit |
|---|
|
|
| | | Non-functional: "Module" Framework and Registry | - Define a family of specifications/interfaces for functional extensions to 'core' DSpace ( working title: 'modules'), and refactor existing bundled code to conform to new model (if appropriate/cost-effective)
- Provide infrastructure/tools for a module registry, where users can discover, and install modular extensions. Likely include both modules maintained by committers and community contributions.
| 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. As "priority 2" features, these features are not guaranteed for the DSpace 7.0 release, but we'd encourage community members to volunteer to help achieve any of these features. If there is community interest in moving one or more of these features forward, that feature may be moved up to "priority 1" for the 7.0 release.) | Priority 2 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Volunteers |
|---|
| 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 | - Primary use case description: Basic Statistics (and all child pages)
- This would likely be depending on the "Single User Interface" project for much of the enhancements, as many of these reports are UI related.
| Goal 1: Fundamentals of IR | x | Medium | | | | Enhance Basic Preservation | - See linked use cases for more details of possible enhancements to existing basic preservation functionality
| 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.) | Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Volunteers |
|---|
| Non-functional: Easier Installation | - Dependent on some Priority 1 features (e.g. Single UI, Configs in Admin UI)
| Goal 5: Low cost, "just works" | x | | | | | Non-functional: Easier Upgrade Process | - Dependent on some Priority 1 features (e.g. Single UI, Configs in Admin UI
- Could be helped by "Theme management in Admin UI"
| Goal 5: Low cost, "just works" | x | | | | | Advanced Usage Statistics | - Likely an optional module or external integration, therefore it may be dependent on a "Module Framework" being developed
- Ranked very highly in 2013-14 Vision Survey
| Goal 3: Can be "extended" | | High | | | | Theme management in Admin UI | - Ranked lower in 2013-14 Vision Survey
| Goal 5: Low cost, "just works" | x | | - NEED a "label" for theme related use cases
| | | Enhance Versioning | - Ranked lower in 2013-14 Vision Survey
| | x | | | Expand |
|---|
| title | Versioning Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 30 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| labels | uc-versioning |
|---|
|
|
| | | 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 | - Likely an optional module or external integration, therefore it may be dependent on a "Module Framework" being developed
- Ranked lower in 2013-14 Vision Survey
| Goal 3: Can be "extended" | | High | | | | Enhance Search / Browse System | - See various unmet use cases labeled "Search/Browse"
- Dependent on "Single Search / Browse System" feature being completed, to ensure we can more easily implement new Search/Browse use cases
- Some use cases also dependent on "Single User Interface" being completed
| Goal 1: Fundamentals of IR | x | | | Expand |
|---|
| title | Search / Browse Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 20 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| labels | uc-browse-search |
|---|
|
|
| | | Enhance Access Control | | Goal 1: Fundamentals of IR | x | | | Expand |
|---|
| title | Access Control Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 20 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| labels | uc-access-control |
|---|
|
|
| |
Integrations| Integration | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Volunteers |
|---|
Integration with external authentication / authorisation system | - Also related to Authentication through Multiple Mechanisms
- Already exists to some extent (LDAP, Shibb, etc). But, would be nice to move to a third-party, standardized AutN/AuthZ solution.
| Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | DS-1566 |
|---|
|
| Goal 4: Integration with external services | x | Medium | | | | Integrations that significantly lower the effort to fill DSpace with content, both from in house systems and third party content | - Some possible metadata/record inputs include CrossRef, DataCite, PubMed, ORCID works, SHARE, etc.
| Goal 4: Integration with external services | x | Medium/High | | | | Integrations that increase the exposure of content stored into DSpace in external systems | | Goal 4: Integration with external services | | | | |
|