The Role of Repository Software

By picturing at the repository as a whole we can identify and locate all the processes and services provided, as shown in the Figure below. Here we can see more clearly the processes involved in collecting content and providing access. Current repository softwares (EPrints, DSpace and Fedora are the best known open source examples) aim to manage these processes and services. They may provide many features from the model but they should never block the user from integrating other services and processes to form a bespoke version of the model.



It can be seen that the core role of the repository software is to manage the various inputs and outputs from the different processes and services. Critically, the repository provides indexes and interfaces to support different access routes, such as user browse or search, or access by other services such as OAI-based search.

Current software provides a number of ingest routes to the repository, such as SWORD and many Web-based mechanisms. This has been an area of particular development over the years as it forms the basis of repository interoperability. Similarly many export and retrieval services have been developed, such as OAI-PMH, RDF and more recently OAI-ORE, which can be used with current repository software.

What happens inside the repository is less obvious. Recent developments have enabled repository software to manage multiple indexes such as required for many database systems as well as semantic stores for RDF-based data.

Through the work of the Preserv project, we now see opportunities to make the repository store process more flexible and, as for ingest and access, offer different services. In this way a repository could use selected storage options to maintain the integrity of data as well as use any specialised functionality made available by the storage provider. Examples could include using the repository to manage offsite backups, object-based storage and cloud storage.