Foundations of DSpace

Today, I visited the DSpace Foundation & those involved with DSpace at MIT to find out more about the Foundation and it's aims, as well as the planned development effort for DSpace 2.0.

Basically, the Foundation was a necessity to provide structure and governance over the redevelopment project. A pivotal role within the foundation is that of Technical Director (yet to be appointed) whose key role for the first 12 months of the project will be to draw consensus from the DSpace community and make informed strategic technical decisions. The person who fills the role will also keep a watching brief on standards and work in the community (e.g. Sun Honeycomb, WARC files, etc.).

The key goals/outcomes of the planned project are implement the following for DSpace:

• Scalability
• Interoperability
• Modularity
• Workflow - enhanced for ingest and preservation; submission and collection management workflows customisable for each collection type.
• Data Model improvements - metadata versioning is available now, and versioning for objects is planned for implementation in version 1.6.

The improvements delivered in version 1.5a:

• customised submission
• event mechanism
• Manakin integration
• Maven build
• More modular; service-oriented - moving away from monolithic; transitioning from individual to interoperable.

Version 2.0 development is planned for May to November 2008. The key changes are encompassed in the data model revision:

• Ability to handle external IDs (Handle, PURL, DOI, etc.) [pardon the pun]
  • feed in any ID an metadata
  • multi-IDs in versioning - internal & external ID
• Capability to store metadata at all levels of the hierarchy in the object data model.

Looking to the future there is also the intention to integrate with other projects and technologies such as GDFR, JHOVE, Bitstream Format Register, Honeycomb, SRB, Petabox.

Key issues I identified for NLA usage:

• No recursive parent-child relationship in data model. This could probably be circumvented quite successfully by relating objects through relationship references within the same Collection.
• Repository metadata is all completely accessible; objects can be restricted. Put simply metadata cannot be restricted and there is no plan to implement this at present, since the history of DSpace is as an access repository. Possible solutions:
  • record restrictions data and implement restrictions in discovery/delivery systems.
  • implement an second repository (DSpace or other) to store all accessible metadata & synchronise it on updates.