The Hybrid Library Revisited Judith Pearce Director, Web services National Library of Australia [email protected] Monica Berko, Director, Applications National Library of Australia [email protected] Abstract: Four years out, this paper revisits the theme of VALA2000 and looks at the extent to which integrated library management systems have been developed to operate as hybrid library systems by focussing on the National Library of Australia’s requirements in this area. A range of commercial portal products now extend (and may eventually replace) the OPAC. However, there is still a gap in the market place for workflow systems supporting the routine digitisation of collection material. In addition, library system vendors are only just beginning to provide the level of support needed by libraries that wish to build innovative web-based services based on the catalogue. Introduction At VALA2000 staff from the National Library of Australia (Pearce et al) delivered a paper on “The Challenge of Integrated Access: The Hybrid Library System of the Future”. The term ‘hybrid library’ had been coined by the elib Electronic Libraries Program (JISC, 2002) to describe systems and services providing integrated access to both print and electronic resources. The elib hybrid library projects used broker architectures to unite heterogeneous ‘provider systems’ under a single user interface. For example, the Agora Project (2001) which had as its aim to build a Hybrid Library Management System (HLMS) was an implementation of the Models Information Architecture (MIA) in spite of the play on the LMS acronym. Such architectures take the content of provider systems as givens and focus on the use cases, schemas and protocols needed to use such systems via a single user interface. By contrast, an Integrated Library Management System (ILMS) deals with the acquisition, description and maintenance of collections as well as resource discovery and delivery. Its role is not just to provide access to a library’s collections but also to support internal operations. The authors of the VALA paper looked at the issues arising from the development of separate systems and processes by libraries for managing physical format and electronic collections and highlighted the need for ongoing development of the Integrated Library Management System (ILMS) to deal with both kinds of collection material. They identified the need for additional technical modules to support the management of electronic resources. This would not only achieve operational efficiencies but also ensure that such resources were described using the same cataloguing rules as other collection items and could be discovered through the catalogue. At the resource discovery end, they argued that the catalogue had a central role to play as a provider system in the delivery of hybrid library services at the local level; and that union catalogues such as the Australian National Bibliographic Database had a similar role to play at a regional or national level. To operate effectively in this role there needed to be a shift in development priorities from the OPAC to the Z39.50 server. Background to the Requirement Twelve months previously as part of its Digital Services Project the National Library of Australia had issued an information paper, outlining its requirements for products that would assist it to develop an integrated approach to digital service delivery (National Library of Australia, 2003). The Library had an immediate need for a system to support the delivery of a service providing access to images held in Australian collections. The first product purchased was thus a Metadata Repository and Search System that could be used to aggregate resource descriptions from a range of sources and to search across other systems using Z39.50 protocols. This was put to use at once to deliver the new PictureAustralia service (http://www.pictureaustralia.org). In the meantime a separate request for tender was released for a Digital Collection Management System. When the VALA paper was presented, the Library had just completed evaluation of responses to the request for tender and had failed to identify a suitable integrated solution to its digital collection management needs. A range of mature products were available in the market place to support the storage of digital objects but digital library applications were still at an early stage of development and did not have the required functionality or modularity. From this exercise, the Library learnt that there was no technical reason to store its digital objects inside a database management system. In fact that there were benefits in keeping the storage and management requirements separate in the logical systems architecture. The Reference Model for an Open Archival Information System (OAIS) provided a conceptual framework that supported this approach through its focus on ‘ingest’, storage and access (RLG, 2002). The ‘Submission Information Package’ received from producers and the ‘Dissemination Information Package’ presented to consumers is opaque to the OAIS compliant archive. Processes to create, collect and describe electronic resources and to ensure their discovery and delivery fall outside the scope of the framework. A range of different functions might be needed to support these processes depending on the community to be served by the archive and the type of material to be archived. The Library had therefore just begun work on the specifications for two separate procurement processes at the time of the VALA paper: one for a Digital Object Storage System and one for a Digital Object Management System. ‘Buy not Build’ In spite of not having identified a suitable product through the previous procurement process, the Library was still determined to take a ‘buy not build’ approach to the digital object management requirement, preferring not to develop software in-house unless off-the-shelf products did not yet exist that met its requirements. In one specific area, however, the Library did decide to develop a software solution in-house. A Collecting System was needed to replace PAMS, a modest system that had already been developed in-house to gather web sites for the PANDORA archive (http://pandora.nla.gov.au). In this area, Australia was ahead of other countries taking on an archive role and suitable products had yet to be developed. The selective approach to web archiving adopted by the Library was resource-intensive. To make the service sustainable there was a need to minimise the cost of collecting each title. A small team of developers embarked on a project to build a workflow system to meet this requirement. By separating the storage requirement from the management requirement and taking workflow support for collecting web sites out of the equation, the Library hoped to find products that could be customised over time to meet its needs. Vendors of integrated library management systems were turning their attention to digital library requirements of their customers. In the broader market place digital asset management systems were being developed for allied communities such as museums and publishers. Digital asset management system vendors were more likely to offer products that could be customised quickly to meet the Library’s needs. They had expertise in different file formats, technical metadata and the processes required to interface with a digital object storage system. They were more likely to have used the latest Java-based technologies to develop their product and to have application-programming interfaces that could be used to develop support for library-specific workflows. Library system vendors had a better understanding of the requirement to treat the intellectual work as the primary object for management and discovery and the need to support collection hierarchies. They also had expertise in library standards such as MARC and Z39.50, thesauri, filing and sorting algorithms and non-Roman character sets. Their business was to improve the operational efficiency of library workflows and it seemed a natural extension for them to develop modules to support the management and delivery of digital collections. However, this was not core functionality needed by all libraries and there was not a high level of support for the requirement in existing products. Preference for an Integrated Solution The Library had a preference for a solution that could form part of an integrated library management system. Since 1996 it had been routinely digitising new picture acquisitions and making them accessible on the web through its Images1 service. Images1 was a stand-alone system using Oracle for its metadata repository and search system and a simple, pre-Dublin Core metadata schema for resource description. Behind the scenes, another stand-alone system based on an Access database - Pictorial Manager - had been developed to enable staff to create batches of pictures for dispatch to an external agent for digitisation and to acquit the batches on their return. This was an inefficient way to operate. Staff needed special skills to use Pictorial Manager and workflows were interrupted at each point where data needed to be transferred from one system to another. Digitisation is expensive and efficiencies in this area make the difference between one-off digitisation projects to showcase treasures and digitisation as a sustainable ongoing operation to open up access to the collections. Regardless of the solution, a key requirement of the product chosen was to enable use of the catalogue server as the master source for resource descriptions and the web interface to the catalogue as the first point of entry to the Library’s collections. The Images1 collection had grown to 20,000 images by 2000 but users were still only able to discover through this service less than 5% of the Library’s collection of over 600,000 paintings, photographs, prints and posters. In addition, much of the material that had been digitised was only described at collection-level in the Library’s catalogue. Users had to know to search both databases to be sure of discovering the full diversity of the collection.