Integrating LMS and repositories

It seems very logical that there should be integration between Library Management Systems (LMS) and repositories, as they are both providing access to resources useful for research, and often for teaching and learning. However, a study for JISC by Strathclyde’s Centre for Digital Library Research in 2009 found that there was often poor integration between LMS and institutional repositories. According to the survey undertaken for the study, the majority of respondents reported that their Library Management Systems were not interoperable with their repositories, although both the LMS and the IR had higher levels of interoperability with other university systems such as HR, VLEs, research administration and assessment.

One problem is that although there is considerable overlap in the contents of the library catalogue and the repository in terms of the institution’s own published output, the metadata and authority standards of the systems are very divergent, with good authority control of author names and subjects in the catalogue and very little in many repositories, for example. The report notes that technical solutions for the integration of systems exist (such as SRU/SRW) but these cannot be sufficient while there is a lack of resources to address deeper issues with content and metadata. Links between the catalogue record for a print thesis and the electronic copy stored in the repository were generally well instantiated in both systems, but links to any other content were not.

Although far from universal, the use of link resolvers to direct users seeking full text from the repository to library holdings (obviously only useful for users entitled to see subscribed content) is increasing.

There has also generally been a level of dissatisfaction with LMSs across the sector, which JISC is addressing with a number of projects. For more details, see here.

The role of next generation discovery tools

There is a great deal of interest in so-called ‘next generation’ discovery tools in libraries, both to create the kind of uncluttered ‘Google’ style interfaces which users have become accustomed to though using search engines, and to integrate different resources better through a single point of discovery, giving users a single set of results.

The LMS providers have realised that their existing systems are not doing the job well, and have begun to provide tools which not only sit on top of their own systems but can be acquired independently of the underlying LMS. Clearly, LMSs are expensive and complex to acquire and implement so many libraries are not going to switch, but may be persuaded to implement a new discovery tool on top. This may provide an opportunity to create an interface which can search across the library holdings and the repository in one operation.

Examples of such tools are Summon from Serials Solutions, Primo Central from Ex Libris, and WorldCat Local from OCLC. These tools also index electronic resources from a wide range of publishers, meaning that users can search both the library catalogue and indexed full text articles from databases at the same time.

 The University of East Anglia has implemented the Primo software so that it can retrieve results from the library catalogue and also the repository (through use of ExLibris’ Digitool). Several UK universities have acquired Summon: for example, Abertay Dundee, Brunel and Middlesex, and Royal Holloway has a beta version operating which searches its repository as part of a single resources search.

Blacklight

The use of Blacklight at Hull originated with the Hydra project, an open source collaboration to create a digital content architecture, between Hull, Stanford and the University of Virginia, all Fedora users. Fedora does not have its own interface, unlike EPrints and DSpace. This can create difficulties – the original interface used at Hull is no longer supported – but also offers the opportunity to create customised views based on the contents of the repository and the way these are modelled. The library at Virginia was already using Blacklight as a next generation library discovery tool, its original purpose, and this suggested the possibility of Hull creating a single route for users into all its ‘internal’ assets – the stock held by the library, the assets in the repository and the university’s archives. Hull was concerned about foregrounding the university’s own resources, which they felt could be overwhelmed in other discovery environments, and also they value the control over their indexing of their own metadata, with the ability to retain the richness of their records. Blacklight could both index their MARC library catalogue records and their Hydra repository index.

This in some ways in a very different approach to that adopted by some libraries, which are moving away from a clear distinction between internal and external resources in the ‘finding’ process, while facilitating the process of ‘getting’ the item, either directly from the library’s subscribed or owned resources, the repository or through making pay-per-view, inter library loan etc. more seamless.

Hosting versus local control

The use of providers like Serials Solutions who create a unified index and host the service means effectively outsourcing the process to a third party. This has the advantage of sharing the burden of technological development and saving resources in the library. Achieving a relevance ranked single results page across all these sources (including third party electronic content) is almost certainly beyond the ability of any one library. The vendor will also include the local metadata for the library’s own collections. However, this approach has its critics, who argue that it is:

“incompatible with an open source we-control-the-software-and-can-add-features approach. Sure, some of these vendors give you limited APIs, allowing you to (at potentially great cost in development time) put your own ‘skin’ on their search, potentially integrating with local systems (for instance, patron account screens) better than the out of the box product. (and some of them don’t give you sufficient APIs for that). But they’re all based on indexes that reside on a vendor’s server, and you don’t have access to change the underlying indexing routines, strategies, fields, etc. Nor will any of these vendors share their aggregated data with you. (Perhaps because of licensing agreements with the providers they harvest from; perhaps just because it would be too much trouble and expense for the limited number of libraries interested in such a service and what those customers would be willing to pay.”[1]

The decision has to lie with local priorities and users – some are questioning whether users in fact want such a unified search at all. Certainly it seems desirable though to enable integration between the catalogue and the repository.

No comments yet.

Leave a Reply