DSpace Updates 3/1/19

Created by Gabe Galson
Last updated: Mar 04, 2019 by Cynthia Schwarz (Unlicensed)
2 min read

The DSpace project team is moving closer to determining how exactly the system we're building will look and function when we go live. While DSpace will form the system's technical core, and will serve at the very least as its administrative interface, it could be possible to 'skin' DSpace, that is, build a separate system through which the public would interact with the items in our IR. We’re currently consulting with

Chad Nelson and Christina Harlow to determine what approach is best out of the three outlined in last week’s blog post.

To review, here are the three options under consideration:

  1. Skinning with a system such as Blacklight, the framework used to create our new Library Search (this could look something like Cornell’s IR).

  2. Extensively customizing DSpace (this could look something like DukeSpace)

  3. Using an out-of-the box DSpace theme (i.e., this example repository)

To weigh the relative merits of each option we used a project management tool called a product requirements matrix, a grid that lists each feature the finished system should be able to perform (read this page for a fuller description). The matrix Gabe Galson made in consultation with the Services and Metadata groups can be found at the top of this page. The Groups ranked each feature's importance, giving it one of four ratings: 'must have', 'should have', 'could have', or 'won’t have'. These rankings, generated by stakeholders, can be cross referenced with a 'difficulty of execution' ranking that can be assigned by by the developers and technical team. Or, they can be consulted by developers who can advise on the best solution. This matrix is a bit more complex than the standard example, as we’re already locked into DSpace as our administrative interface, and whatever front end approach we decide on must take this into account. This means, for starters, that certain features requested by the Groups could either be fulfilled via DSpace, or via the second system, depending on the approach we take. It also means that the fact that a feature is front end (relating to the interface) or back end (relating to the administration of the objects and metadata the system contains) is important, as it determines whether it can be done through DSpace’s out-of-the-box functionalities, or whether it must be rebuilt in the second system. Note that the matrix is still a work in progress, and will be revised and brought back to the Services Group for further review. Stay tuned!