Alternatives to Repositories

"Existing systems such as CMSs, portals, or collaborative working environments can fulfil some of the requirements [of a repository]. However they do not provide the rich tools for ongoing access and discovery found in repository software..."

The decision of whether to use a repository for managing digital content is often challenging as it is highly likely that digital assets already reside in many types of systems. These range from locally-written closed systems to the open web. In the modern Higher Education information environment there are now typically many systems which each provide similar functionality and it is often a difficult decision to decide which system is the most suitable home for different sets of information.

One issue that may prevent busy academic staff depositing learning and teaching content is the fact that they may be required to deposit in many places, particularly if being mandated to deposit in a national and/or institutional repository. Academics may be more inclined to deposit in a subject community repository or system or just make their content available on the open web through a web site. Using an institutional repository or even a VLE that can feed content into other systems presents a more compelling reason to deposit. Any system needs to integrate with others in a way that results in 'once only' deposit.

Requirements Analysis

While content management systems (CMS), portals, Virtual Learning Environments or collaborative working environments could effectively fulfil some repository requirements, they do not typically provide the ability to expose digital content to the wider world. In addition, the ability to export and import bibliographic data with such systems is often poor or non-existent. Dedicated repository software provides a complete set of features. Before examining possible institutional information architectures and the potential inclusion of repositories into that architecture, it is useful to consider the varied functional requirements of an institutional repository. Different drivers have an impact on this and may even compete with each other.

For example there may be an institutional commitment to publish the intellectual output of the University on the open web which may clash with a desire to remain competitive and protective in terms of course content. Some institutions keep these two functions apart in different systems but more are taking the challenge of bringing the two together. Specific functionality that may be required by an institutional repository may include:

• Open Access: Some items may need to be made available online. This includes both the metadata, licencing/use information and the item in an appropriate digital format. Where items cannot freely be made available online, the facility to restrict access is required. Institutions may need to include different 'degrees of openness' for different items.

• Search engine indexing: Sites that store materials should be accessible to crawlers and indexers in order for items to be found by conventional search engines

• Bibliographic metadata: Items often come with associated metadata (title, author names, bibliographic citation etc). These details need to be stored along with the item, in a recognised metadata schema such as Dublin Core1 or MODS2. The ability to 'crosswalk' between metadata schemas is also important

• Export functionality: A common aim of repositories is to export citation details on a per-author basis to automatically generate researcher CVs or RAE forms, or more generally to export data into bibliography manager or data analysis tools. Good export functionality can be necessary to fulfil this requirement

• Import functionality: Some institutions have publication management systems or traditional websites and want to import that data into a repository for public access

• Metadata harvesting: Search system providers such as Intute Repository Search and OAIster use a specialist protocol known as the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) rather than normal web crawling, which cannot accurately harvest metadata. In order for a site to be indexed by specialist search services such as these, an OAI-PMH interface is required

• Persistent identification: In order to facilitate ongoing access to resources within a repository, repository software utilises tools to assign persistent identifiers. Some repository platforms make use of external identifier resolution services to ensure the identifiers would even persist if the domain name of the server or institution changed

• Licencing section

• Content packaging

Integration with other systems

Repository software solutions need not be standalone systems, and can work effectively when integrated with other systems in the information architecture of an institution. Two typical examples of repositories working alongside other systems might be:

• Using a collaborative working environment such as SharePoint, authors can create, manage and apply version control to work. The work can then be published along with its metadata in the repository for final dissemination

• If an institution has web pages in its CMS about members of staff, research CVs (publication lists) can be automatically generated from items in the repository and imported into the CMS

Conclusion

Existing systems such as CMSs, portals, or collaborative working environments can fulfil some of the requirements identified in the list above. However they do not provide the rich tools for ongoing access and discovery found in repository software, nor do they typically provide OAI-PMH interfaces. Furthermore, the ability to export and import bibliographic metadata is often poor or non-existent.

Given that these characteristics are increasingly perceived as essential to making academic output widely available over the web, a strong case can be made for integrating a repository into institutional information architectures, or even using a repository to replace existing systems, as only dedicated repository software provides this complete set of features. The key to making this decision lies in a comprehensive assessment of functional requirements and comparative analysis of existing systems with the intended repository solution.