Candidate Features for DSpace 7.0 - Priority 1The DSpace 7.0 release is under development and the latest status can be found at DSpace Release 7.0 Status. The below candidate features are ordered in terms of importance to the 7.0 release. As such, the goal is to achieve each feature in the order that they appear (and not all features are guaranteed to be completed in time for 7.0). 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. For larger features/contributions, we recommend first forming a Working Group (anyone can chair or form a Working Group) to allow other institutions to contribute to your initiative. Priority 1 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Work in Progress? |
---|
Anchor |
---|
| Single User Interface |
---|
| Single User Interface |
---|
|
Single User Interface. (Work has begun in DSpace 7 Working Group) | DSpace currently maintains two user interfaces in parallel (JSPUI and XMLUI). To replace these two user interfaces, we are building a new, single, out-of-the-box user interface on Angular.io. | Goal 2: Lean and flexible | x | High | For reference: Also see: DSpace 7 UI Project Plain Language Summary | | Anchor |
---|
| Standards-based REST API |
---|
| Standards-based REST API |
---|
|
Standards-based REST API (Work has begun in DSpace 7 Working Group) | DSpace's current REST API, while functional, is limited in features and does not follow current best practices for RESTful APIs. To support the new, single user interface (on Angular.io), we are building / designing a new REST API that follows modern best practices such as: HATEOAS, ALPS, and using the HAL response format. The new REST API is being built using Spring technologies (Boot, MVC, and HATEOAS). | Goal 3: Can be "extended" and Goal 4: Integration with external services | x | High | New REST Contract (work in progress): | | Anchor |
---|
| Single Approval Workflow system |
---|
| Single Approval Workflow system |
---|
| Single Approval Workflow system. (Work has begun in DSpace 7 Working Group) | DSpace currently has two approval workflow systems: - Basic/Traditional Approval Workflows. These are enabled by default, and provide up to three approval steps: "Approve/Reject", "Approve/Reject/Edit", or "Edit". These are described in more detail in the Functional Overview#WorkflowSteps
- Configurable Workflow (XMLUI only, and requires migrating all Basic/Traditional workflows)
We should consolidate on a single Approval Workflow system, likely the Configurable Workflow, with sane defaults. | Goal 1: Fundamentals of IR | x | Medium | See this ticket for more details:
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | DS-3041 |
---|
|
| Goal 1: Fundamentals of IR | x | Medium | | Anchor |
---|
| Single built-in Statistical Engine |
---|
| Single built-in Statistical Engine |
---|
| Single built-in Statistical Engine (SOLR Statistics)
Elasticsearch Usage Statistics were deprecated in 6.0 and will be removed in 7.0
| DSpace currently has three built-in statistical engines, one based on Apache Solr (default), another based on Elasticsearch (optional), and a third Legacy statistics (which parses logs). DSpace should only provide one out-of-the-box, built-in statistical engine (Solr Statistics), and all others should be removed (and as necessary, their features merged into one).
| Goal 2: Lean and flexible | x | Medium | | | Anchor |
---|
| Configurations in Admin User Interface |
---|
| Configurations in Admin User Interface |
---|
| Configurations in Admin User Interface | DSpace should support the modification of most configurations/settings from the Administrative User Interface, instead of requiring such configurations be tweaked from command line.
- 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 |
---|
cql | label = "uc-configuration" and space = "DSPACE" |
---|
labels | uc-configuration |
---|
|
|
|
| Anchor |
---|
| Module Framework and Registry |
---|
| Module Framework and Registry |
---|
| Non-functional: Module Framework and Registry
| DSpace needs a clear definition of what constitutes a "DSpace module", so that third-parties can create, maintain and distribute their own "modules" as add-ons to DSpace, and distribute them via a public "registry". | Goal 3: Can be "extended" | x | High | | | Anchor |
---|
| Lower the effort to deposit content |
---|
| Lower the effort to deposit content |
---|
|
Lower the effort to deposit content (via integrations) | The DSpace deposit process should integrate more closely with external data sources, in order to automatically populate (or suggest) data on deposit. We should also investigate whether some integrations may allow opportunities for Administrator's to autopopulate DSpace from trusted, external content sources. | Goal 1: Fundamentals of IR Goal 4: Integration with external services | x | Medium | | |
Short Term - Priority 2As "priority 2" features, these features are not guaranteed for the next DSpace release, but are still seen as a priority in an upcoming release. Nonetheless, 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 next release. These features are ordered in terms of importance, but are all considered to be lower importance than the "priority 1" features listed above. Priority 2 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Work in Progress |
---|
Anchor |
---|
| Hierarchical Metadata Support |
---|
| Hierarchical Metadata Support |
---|
|
Hierarchical Metadata Support | DSpace should support hierarchical metadata formats (e.g. MODS) | Goal 1: Fundamentals of IR | x | High | | | Anchor |
---|
| Relationships between Objects |
---|
| Relationships between Objects |
---|
|
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 | | | Anchor |
---|
| Simplify Community and Collection Hierarchy |
---|
| Simplify Community and Collection Hierarchy |
---|
| Simplify Community and Collection Hierarchy | DSpace's required hierarchy of Communities and Collections should be replaced with a more flexible module of supporting Collections & Sub-Collections. | Goal 2: Lean and flexible | x | High | |
| Anchor |
---|
| Enhance Basic Statistical Reporting |
---|
| Enhance Basic Statistical Reporting |
---|
|
Enhance Basic Statistical Reporting | DSpace's existing Statistical Reporting user interfaces are rudimentary and do not provide enough useful views/reports/exports of the underlying captured data. These should be enhanced based on modern use cases/needs.
- 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 | | | Anchor |
---|
| Enhance Basic Preservation |
---|
| Enhance Basic Preservation |
---|
|
Enhance Basic Preservation | DSpace's existing basic preservation functions (format identification, checksum verification, etc) could use enhancement based on modern tools and services.
- See linked use cases for more details of possible enhancements to existing basic preservation functionality
| Goal 1: Fundamentals of IR | x | Medium | | | Anchor |
---|
| Easy and Intuitive Deposit Interface |
---|
| Easy and Intuitive Deposit Interface |
---|
| Easy and Intuitive Deposit Interface | DSpace's deposit interface could use enhancement for a better overall user experience with regards to usability and accessibility.
- Dependent on / related to "Single User Interface"
- Primary use case description: Easy and Intuitive Deposit Interface
- May need further definition around what sorts of changes will make deposit easier?
| Goal 1: Fundamentals of IR | x | Medium |
Expand |
---|
title | Other Deposit Use Cases |
---|
| Content by Label |
---|
showLabels | false |
---|
max | 20 |
---|
spaces | DSPACE |
---|
showSpace | false |
---|
cql | label = "uc-deposit" and space = "DSPACE" |
---|
labels | uc-deposit |
---|
|
|
| |
|