DSpace 2015-18 Strategic Plan - Technology

Work in Progress

This is an active document. It is not at all finalized, and may change drastically in the coming months as the DSpace RoadMap Working Group and Steering Group create a final draft for presentation at OR15.

Early comments / suggestions are welcome!

While this document is a work in progress, we do still encourage any community members to add thoughts, comments, questions or clarifications.

We only ask, if you type your comments inline, PLEASE add your name next to your comments. That way we can follow-up with you, as necessary, to ensure your questions/comments have been addressed.

(Very Rough) Summary

Over the last few years, the Steering Group along with various strategic working groups have validated the following vision statements which describe the goals of the DSpace open source product:

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.
DSpace will be "lean", with agility and flexibility as primary goals.
DSpace will include a "core" set of functionality that can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools
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"
DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)

These five statements lead us to a proposed "value proposition" for the DSpace platform (DRAFT)

DSpace is a turn-key web application for maintaining, disseminating and promoting the digital resources or digital output of an organization and its members.

Based on this proposed value proposition and vision statements, the Steering Group recommends the following actions corresponding to each goal:

Goal 1: DSpace will focus on the fundamentals of the modern "Institutional Repository" use case.

In November 2002, DSpace was initially announced as an out-of-the-box "institutional repository software platform" (see DSpace 1.0 release announcement). While that basic goal has not changed, the common needs and use cases of an "institutional repository" have changed significantly in the last decade or so. Therefore, this goal is oriented towards striving to retain DSpace's niche while revitalizing it to meet current and future use cases associated with the modern repository platform.

Action 1A: Verify and validate the needs of a "modern institutional repository". This is instrumental in formalizing the value proposition of DSpace.
- This activity has already begun part of the 2014 Vision Survey and Use Case gathering. However, the gathered use cases still need further analysis, cleanup and prioritization
Action 1B: (Do we want another, post OR15 survey of the community based on Strategic Plan, Tech Roadmap & Use Case gathering?)
Action 1C: Clarify and improve the DSpace value proposition. Enhance our message and goals of the project going forward.
- Mention establishment of the new "Marketing Working Group"

Goal 2: DSpace will be "lean", with agility and flexibility as primary goals

[summary of goal]

Action 2A: To be "lean", the DSpace technology platform should avoid duplicative functionality except where necessary to meet use cases or achieve "flexibility" goals. Where unnecessary duplicative functionality already exists, the technology team should choose a "best option" solution, or propose building a new solution when a "best option" does not exist.
- Examples of unnecessary duplicative functionality
  - maintaining multiple User Interfaces (JSPUI vs. XMLUI)
  - maintaining multiple search/browse systems (Solr vs. Lucene)
  - maintaining multiple built-in statistical engines (Solr vs Elastic Search)
- Examples of necessary duplicative functionality. Each of these duplicative functions would be considered in line with use cases or supportive of our goal for "flexibility" (of data import/export/storage).
  - supporting multiple database storage backends (PostgreSQL, Oracle, etc.)
  - supporting multiple interfaces for deposit (SWORD, REST, etc.)
  - supporting multiple interfaces for export (OAI-PMH, REST, RDF, etc.)
  - supporting multiple external identifier schemes (Handle system, DOI, etc.)
Action 2B:

Goal 3: DSpace will include a "core" set of functionality that can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools

Assigned: Richard Rodgers

[summary of goal] DSpace can be extended. Easy API, etc.

Action 3A: (Streamline the core functionality, and provide a better "plugin" model for third-party plugins)
Action 3B:

Goal 4: 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"

Assigned: Bram Luyten

To provide easy and out of the box integration aspects with external services in the following areas:

Action 4A: Metadata ingest from external services (complete records/items)
Action 4B: Consuming external authority control sources for enriching DSpace item metadata
Action 4C: Exposing metadata and content to external services
Action 4D: Exposing usage statistics to external services
Action 4E: Integration with Authentication and Single Sign on services

To integrate with parallel projects and initiatives (fedora, hydra, islandora) we first need to pin down the use cases of what those integrations will bring to DSpace, or what these will bring to the other platforms. They currently do not fit immediately in any of these five areas.

More examples are in the comment below, but those are probably already too detailed for this page and should end up in the technology document.

Goal 5: DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)

Assigned: Stuart Lewis