Dspace – Digital Repository Dawn Petherick, University Web Services Team Manager Information Services, University of Birmingham MIDESS Dissemination event, 4 th May 2007

Overview of MIDESS at Birmingham  Why did we get involved?  Local objectives  A pilot  Outcomes

Overview of Features  OAI-PMH Compliant Data Provider  Support for custom metadata schemes  Delegated collection management  Persistent URL’s (via handle service)  Unrestricted file format support  Unicode enabled  Web based administration (for common tasks)

Communities, Collections & Items  Items: Items are the compound digital objects held within the repository. They usually consist of a metadata record and any number of files. Items can be mapped so that a single item can be found in many collections. Dspace uses the concepts of communities and collections to manage the hierarchy of Items with the repository.

Communities, Collections & Items II  Collections: All Items are held in one, or more collection in the repository. Each collection can have it’s own copyright notice and submission licence and authorisations or it can inherit these from it’s parent community.  Communities: All collections are held in a community. Each community can hold multiple collections or other sub-communities but cannot hold items.

Users & Groups  Internally DSpace creates it’s own “e-person” record to manage user rights over collections & items.  Users can be assigned to groups which can hold devolved authorisation over collections & items.  If no specific authorisation is given, then the parent collection/community rights are applied.  Item submissions can be moderated by a collection administrator before being added to the collection.

Users & Groups II  DSpace can also use LDAP (Lightweight Directory Access Protocol) to manage central authentication.  This feature can be used to create a DSpace e- person record if one doesn’t already exist.  This method could be used to define a group for an LDAP user, although this requires modifications to the source code.  Shibboleth authentication may now be available as a third party patch.

Custom Metadata  On a default installation DSpace stores an items metadata record using a Qualified Dublin Core scheme.  This can also be extended with additional qualifications and elements not found in Dublin Core if required.  However, it maintains the same format for the new field as QDC; a metadata element with a single optional qualifier.

Custom Metadata II

Custom Metadata III  Adding a new metadata field to the registry does not add that field into the submission workflow.  The workflows can be altered for each collection, but can only be altered within the xml configuration files within the DSpace source code.  Following a change to these files rebuilding and redeploying the web application is necessary.  Other areas need deeper changes to the source code to reflect the changes to the metadata registry.

Item Import & Export  DSpace includes command line functionality that that is used to manage the batch import / export of items within the repository.  This function was primarily designed as a backup and restore for server migrations. It could however be used to transfer collections between institutions if required.  This facility can also be used to export items into a METS object, using DC → MODS conversion for the metadata. Currently there is no analogous METS import facility

OAI-PMH Compliance  DSpace provides a target interface to the items held within the repository, compliant with OAI- PMH protocol version 2.0.  OAI-PMH provides support for multiple metadata formats to be provided by the target, as such DSpace exposes metadata in oai_dc & mets.  DSpace also provides a plug-in system for additional metadata formats such as those created by the JISC Repository Bridge project.

OAI-PMH Compliance II  DSpace doesn’t provide an OAI-PMH client, so it is not possible to point DSpace to another target repository and ask it to fetch all of the metadata records to be included within the local searches.  As part of the MIDESS project we’ve been investigating the creation of a separate program that would act as a harvester and output objects which could then be imported into DSpace using it’s import program.

DSpace’s Weaknesses  Lacks substantial support for importing external (non-DSpace) items.  Currently no support for packaged compound items such as Learning Objects, beyond storing the zip file with a metadata record.  Manages View/Open in the same way for all types of files, by sending the output over the http connection to the browser and letting that decide how to open the file.

DSpace’s Weaknesses  File level metadata within items is very limited and files cannot be structured within an Item.  As DSpace is open source software it relies on the community of users & developers for support and documentation. Support is generally limited to mailing lists (which are usually very helpful) but the published documentation can lag behind the released version of the software.

DSpace version 1.5  The DSpace community is currently working on release 1.5 of the repository and are currently listing the following key improvements:  Interface layer will be changed to support the manakin xml user interface system which should enable a higher level of customisation to be achieved.  Underlying changes to the way DSpace manages changes to the data model of the repository.

DSpace version 1.5  New mechanism for supporting Add On’s within Dspace. This should make it easier to distribute and install additional functionality to the core DSpace package.  General bug-fixes and community patches, as released on the projects source forge pages. The roadmap for DSpace can be found at:

Further technical questions…  Contact Matt Martin, Digital Library Technical Analyst at or tel:

The way forward for U of B?  Evaluate e-prints v3  Discussions with e-learning colleagues about RLOs  Recommendations/Repository Strategy for Senior Management: –Open source vc commercial –One vs many repositpories