? | | | x | Medium | 2 |
Statistics | Filter Usage by Referrer Domain | Administrator | | | | Medium | 3 |
Statistics | Include item usage statistics on public-facing item pages | End User | - Seems like an improvement to Basic Stats
- Added as a child to Basic Statistics
- As implied in use case, may need to be configurable
| | x | Low | 2 |
Statistics, Reporting | More robust and configurable statistics reports | Administrator | | | | Medium | 3 |
Statistics | View number of times an item has been included in search results | Administrator | - Unsure how widespread this use case is?
| | | Medium | 4 |
Statistics | View Statistics Collection by Collection and Community by Community | Administrator | | | x | Medium | 3 |
Integrations, Access Control, Configuration | Integration with external authentication / authorisation system | Administrator | - Already implemented through LDAP, Shibboleth, and CAS support.
- Perhaps needs OAuth support in the future?
| Goal 4: Integration with external services | x | Medium | 2 |
Integrations, Access Control, Configuration | Authentication through Multiple Mechanisms | Administrator | - Not only integrate with external authentication services, but allow multiple external authentication options on a single service.
- Already implemented via Authentication Plugin mechanism?
| Goal 4: Integration with external services | x | Medium | 2 |
Integrations, Metadata | Linking to other data sources search for available data | End User | - Quite tricky. May be hard to match metadata sources. Some sources may need a subscription.
- Perhaps easier to implement through a method such as "Provide DOI, DSpace will find all the metadata"
| Goal 4: Integration with external services | | High | 4 |
Integrations | Use of multiple sorts of Direct Object Identifiers | Administrator | - Adding CrossRef DOI support
| Goal 4: Integration with external services | | Medium | 3 |
Integrations, Deposit | Importing large files into repositories using an external system | End User | - Overlap with lots of 'deposit' use cases
- Can be implemented via SWORD? Perhaps therefore not a DSpace requirement as such?
| Goal 4: Integration with external services | | Medium | 4 |
Integrations, User Experience | Linking to repository content through a learning management system | End User | - Could be performed using LTI (Learning Tools Interoperability)
- Or could be implemented with a simple 'share this' type of approach
| Goal 4: Integration with external services | | Medium | 4 |
Integrations, User Experience | Integrating with third party document streaming services | End User | | Goal 4: Integration with external services | | Medium | 3 |
Integrations, Deposit, OAI | Importing data from discipline-specific systems into DSpace | End User | - This could be implemented as a pull from an external system, or as a push from the the external system.
- Maybe SWORD deposit, or OAI-PMH harvesting
| Goal 4: Integration with external services | | Low | 4 |
Integrations, Deposit, OAI, User Experience | Integrations that avoid registering information multiple times within the organisation | End User | - Overlaps with a lot of other content harvesting or deposit use cases
- Hard to describe as it could vary in so many ways according to the institutional setup of systems
| Goal 4: Integration with external services | | Low | 5 |
Integrations, OAI | Integrations that increase the exposure of content stored into DSpace in external systems | End User | - Could be as simple as ensuring there is an OAI-PMH interface for harvesting the content into external search systems or aggregators
| Goal 4: Integration with external services | x | High | 2 |
Integrations, Deposit, OAI, User Experience | Integrations that significantly lower the effort to fill DSpace with content, both from in house systems and third party content | End User | - External harvest of other sources, e.g. via the existing OAI-PMH harvest functionality
| Goal 4: Integration with external services | x | High | 2 |
Integrations, User Experience, Metadata | Integrations - Enrich metadata fields with external geographic information | End User | - Either basic links to an external resolver / geo parser, or better in-built handling of geo data (PostGIS?)
| Goal 4: Integration with external services | | High | 5 |
Integrations, User Experience | Integrations - Personal Identifiers (ORCID) | End User | - Would ORCIDs be implemented using the current controlled authority plugin system?
| Goal 4: Integration with external services | x | High | 3 |
Integrations | Integrations - Support ORCID in Authority Cache | Administrator | - Implement a link to ORCID identifiers. Include the ORCID in the user profile, but cache supplemental information in an index such as solr
| Goal 4: Integration with external services | x | High | 3 |
Integrations | Integrations - Support for ORCID in the CSV Batch edit | Administrator | - Include ORCID identifiers in the batch CSV editing functionality.
- Need to decide how to relate ORCIDs to author name strings in the DSpace data model, and then how to represent those in the CSV.
| Goal 4: Integration with external services | x | High | 3 |
Integrations | Integrations - Handle System Identifiers | Administrator | | Goal 4: Integration with external services | x | High | 1 |
Integrations | Integrations - Persistent Identifiers other than Handles (DOI) | Administrator | - Two aspects to this: different identifiers (DSpace now supports DataCite), but also identifiers for more than just items, for example for bitstreams
| Goal 4: Integration with external services | x | Medium | 4 |
Integrations, Deposit | Integrations - REST API | Administrator | - Full REST API allowing all CRUD functions, not just READ operations
- Exists in DSpace 5.x
| Goal 4: Integration with external services | x | High | 4 |
Integrations, OAI | Integrations - Support Standard Repository Machine Interfaces (OAI-PMH, SWORD, ResourceSync) | Administrator / End User | - Ensure DSpace works in the wider scholarly systems landscape
- OAI-PMH, SWORDv1 and v2 are all already supported
- ResourceSync not yet core in DSpace distribution
| Goal 4: Integration with external services | | Low | 4 |
Integrations | Integrations - Search Engine Optimization | Administrator | - Ensure DSpace user interfaces maintain best practice in this area
| Goal 4: Integration with external services | x | High | 3 |
Structure, Configuration | Associate Separate Properties with Each DSpace Community | System | - Seems like an implementation suggestion for how to support different settings/configs/themes on different Communities/Collections
| | | | |
Structure, Deposit, Integrations | Automated Deposit of New Items | System | - Seems to be implemented already via SWORD, but would be dependent also on an external service to auto-deposit
| Goal 4: Integration with external services | | Low | 3 |
Structure, Editing, Versioning | Automated Retention of All changes to Items | System | - At least partially implemented via versioning. But may need to be more in-grained into DSpace architecture
| Goal 1: Fundamentals of IR | x | High | 1 |
Structure, Deposit, Integrations | Automated Update of Existing Items | System | - Seems to be possible via SWORDv2 and REST API
| Goal 4: Integration with external services | x | Low | 3 |
Structure, Content Model | Community and Collection hierarchy (or generic containers) | System | - Frequently discussed request, and a likely simplification of our content model
| Goal 2: Lean and flexible | x | High | 1 |
Structure, Content Model, Deposit | Create / manage files and metadata (as an Item) | System | - Overlaps with End User - Batch Deposit
- Also describes flexibility of the Item / Bitstream hierarchy, but it's unclear if that's a high priority or not.
| Goal 2: Lean and flexible | x | High | 2 |
Structure, Content Model, Browse/Search | Create the ability to place "dynamic collections" (pre-faceted view of a collection) within the community hierarchy. | System, Administrator | - Sounds almost like creating a "collection" via a "Saved search"
| | | Medium | 3 |
Structure, Content Model, Deposit, Metadata | Describe Individual Bitstream within an Item | End User, Administrator | - Now possible cause of the "Metadata on all objects" added in DSpace 5
- Just requires new UIs to be built to add such metadata on Bitstreams
| Goal 1: Fundamentals of IR | x | Medium | 2 |
Duplicate | Drag and drop opportunities for changing collections structure | - | | | | | |
Configuration, Deposit | Manage Lists, Controlled Vocabularies and Authority Control | Administrator | | Goal 5: Low cost, "just works" | x | High | 2 |
Incomplete | Management of Deposits / Submissions | Administrator | - This use case is vague and seems better described in other use cases (see page for comments)
| | | | |
Structure, Editing, Versioning | Manual Creation of "New Editions" of an Item | End User, Administrator | | Goal 1: Fundamentals of IR | x | Medium | 2 |
Structure, Editing, Versioning | Manual Edit of Existing Items | Administrator | | Goal 1: Fundamentals of IR | x | Low | 3 |
Structure, Deposit | Manual Submission of New Items | End User | - Already implemented, except where other use cases describe enhancements
| Goal 1: Fundamentals of IR | x | Low | 3 |
Structure, Content Model, Metadata | Metadata for all levels of object hierarchy | System | - Exists in DSpace 5 (at DB and API layers)
- Just may require new UI pages to be built
| Goal 1: Fundamentals of IR | x | Medium | 2 |
Structure, Content Model | purpose of bundle layer | System | | Goal 1: Fundamentals of IR | x | Medium | 2 |
Structure, Content Model, Relationships | Relationships between objects | System | - Ranked very highly in 2013 Vision Survey
| Goal 1: Fundamentals of IR | x | High | 1 |
Structure | Simple AssetStore for Human Traversal | System | - Unclear how popular this would be, and whether it cause some performance issues
| | | Medium | 4 |
Structure, Content Model, Relationships | Support for derivative objects | System | | Goal 1: Fundamentals of IR | x | Medium | 3 |
Structure, Content Model, Metadata | Support for hierarchical metadata formats (e.g. METS / MODS) | System | - Often talked about / requested, but quite complex to implement in our current data model
- Ranked in the "middle" of the 2013 Vision Survey
| Goal 1: Fundamentals of IR | x | High | 2 |
Structure, Editing, Versioning, Preservation | Generated provenance for all added bitstreams | System | | Goal 1: Fundamentals of IR | x | Medium | 3 |
Structure, Content Model, Relationships | Apply licenses to bitstreams | End User, Administrator | | Goal 1: Fundamentals of IR | x | High | 3 |
Structure, Metadata, Preservation | Generate technical metadata per bitstream | System | | Goal 1: Fundamentals of IR | x | Medium | 3 |
Integrations, User Experience | Streaming Image Server (integration) | System | | Goal 4: Integration with external services | | Medium | 3 |
Integrations, User Experience | Image file display (pan, zoom, size options) | End User | | Goal 4: Integration with external services | | Medium | 3 |
Deposit, Integrations | Email Deposit | End User | | Goal 4: Integration with external services | | Low | 2 |
Workflow | Workflow overview | Administrator | - Use case may need more details. What info would be useful, etc.
| Goal 5: Low cost, "just works" | x | Low | 2 |
Configuration, Deposit | Format checking of data entry in input forms | Administrator | | Goal 5: Low cost, "just works" | x | Low | 2 |
Configuration, Deposit | Check Bitstream names against allowed file name pattern | Administrator | | Goal 5: Low cost, "just works" | x | Low | 3 |
Structure, Content Model | Simplify Collection Creation Based on Template | Administrator | - Seems like a potential quick win in creating Collections/Communities
| Goal 5: Low cost, "just works" | x | Low | 2 |
Configuration, Browse/Search | DSpace should accommodate basic index normalization | Administrator | | Goal 5: Low cost, "just works" | x | Medium/High | 3 |