Page History

...

DSpace 3-5 Year Vision Statement (Draft)

The following statements describe, at a high level, what goals the DSpace open source product should strive to meet:.

1. DSpace will focus on the fundamentals of the modern "Institutional Repository" use case. We are striving to meet the IR needs of the next 5-10 years.
2. DSpace will be

...

1. "lean", with agility and flexibility as primary goals.
2. DSpace will include a "core" set of functionality that can be "extended" (think

...

1. plugins) or have "hooks" (integration points) to complimentary services/tools
2. DSpace will be designed in such a way that it can be easily/quickly configured to integrate with new & future tools/services in the larger digital scholarship "ecosystem"
3. DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)

For more details about each of these goals, about possible fundamental IR use cases, please see the "DSpace Use Cases & / Features listed " section below.

DSpace Use Cases / Features (Draft)

What follows is a (rough) listing of core use cases & features that DSpace should strive to meet, based on the "3-5 year vision statement" detailed above. 

These lists are by no means final, they are just an initial brainstorm of organizing use cases and features into three main categories: "Primary / Core Features", "Possible Extension/Plugins", "Likely Extensions/Plugins".   The goals are to generate discussion and attempt to determine which use cases/features are fundamental to all DSpace users and which could be provided by a (third party or centrally maintained) plugin/extension.

Primary / Core Features

The following features are considered seem to be primary use cases of DSpace. Therefore, these features should likely be immediately available in "out-of-the-box" DSpace and should require no extra installation/setup:

• Basic Functionality:
  
  • Create, Read, Update Delete (CRUD) on objects
  • Versioning of objects
  • Basic Search & Browse functionality
  • Basic Preservation functionality (e.g. Fixity checks)
  • Basic Statistics (or "hooks" into external statistics engines)
• Content Model
  
  • Should support a Community & Collection "like" hierarchy 
    
    • Doesn't necessarily require Communities and Collections to be separate object types. They could just be a single "Container" type of object.
  • Items are the primary type of object.  Items include File(s).
    
    • Note: Old concept of "bundles" may need rethinking.
  • New object type:  Author objects
    (which hold metadata about authors/researchers in the system)
  • Persistent Identifier support for all objects
  • Support for object derivatives (e.g. thumbnail images)
  • More flexible relationships between objects
    
    • Including aggregations of objects & complex objects
• Metadata
  
  • Structured Metadata
  • Metadata should be at all levels of object hierarchy.
    
    • Administrative/Preservation Metadata at all levels, including on individual Files
  • Hierarchical Metadata formats should be supported
• Upload / Download of Content:
  
  • Self deposit & mediated (approval workflow based) deposit of content
  • Batch Deposit of content (from a UI)
  • Batch Download of content (from a UI)
  • Large File support for End Users
    
    • End Users should be able to upload and download large files themselves
• Access controls (Authentication & Authorization)
  • Authorization controls at all levels of object hierarchy
  • Also includes Embargo-style access controls
• User Interface Functionality
  
  • Single, default out-of-the-box User Interface
    
    • Preferably some sort of template-driven UI framework
  • User Interface should be "SEO Friendly"
  • Configuration Management takes place in the UI
  • UI Template/Theme Management takes place in the UI
• Standard Machine Interfaces
  
  • Some high priorities: OAI, SWORD, REST API
  • When possible, machine interfaces should be able to target content at any level (Community, Collection, Item, File, Author)
• Licensing support
  
  • Both deposit license and Creative Commons licensing
• Ability to easily "hook" into external tools & services
  
  • e.g. something like Curation Tasks & other more robust ways to integrate with other tools/services

Possible Extensions / Plugins

The following features may or may not be available in "out-of-the-box" DSpace. It's arguable whether these are primary use cases that DSpace should support. It's possible some of these features could be handled by plugins which you install in DSpace, or by "hooks" into external services/tools.

• Richer Licensing support (individual CC licenses on individual files)
• Support for Delivery of Media
  
  • Doc Viewers / Page Turners
  • Geospatial
  • Streaming content
• Alt-metrics (downloads, tweets, etc.)
• Support for small scale research data sets
  
  • Relationship back to publication (linked)
  • Also may include software programs
• Metadata extensibility
  
  • Stronger support for channeling user contributed metadata
  • Schema agnostic
• Compliance with Open Access directives (of various countries)
  
  • models to track with general worldwide OA directives
  • when possible, methods to check compliance
  • when possible, support for automated evaluation
• Improved Statistics (could be external, e.g. Google Analytics)
• Improved Support for External Identifiers (DOIs. Handles, etc.)
• Customized / Flexible UI support
  
  • e.g. Users should be able to change their Collection's "theme"
    or "template"

...

Likely Extensions / Plugins

The following features are NOT considered seem to not be primary use cases/needs of DSpace. Therefore, these features would likely NOT be provided by "out-of-the-box" DSpace.  They would either need to be implemented as plugins to DSpace, or DSpace would integrate into external services/tools which provide these features.

...