Co-operative models of document delivery: the SEREN project

Alun Hughes
North East Wales Institute of Higher Education

SEREN is a project under the document delivery strand of the Electronic Libraries Programme. The name stands for Sharing of Educational Resources in an Electronic Network; "seren" is also Welsh for "star." The project had two main aims. The first was to develop a suite of software to automate the discovery, request, scanning and electronic transmission of documents, and the second was to test the software in a consortium of Welsh higher education libraries. We hoped to show that with suitable supporting software, the stock of the libraries collectively could be cost-effectively exploited, in comparison with the costs of sourcing documents elsewhere, for example from the British Library.

The project was led by the University of Wales, Bangor, with software development taking place at Cardiff University and the North East Wales Institute of Higher Education in Wrexham. The software development took longer than we had anticipated, in common with many other eLib projects – or, indeed, perhaps most software development projects. The result was that the testing phase has had to be abbreviated, and, so far, restricted to service trials which have demonstrated that the software works, but the consortium is as yet untried. This paper therefore concentrates on the technical features of the software, its functionality, the standards and protocols employed, the problems and technical issues encountered, and scalability and internationalisation issues.

One of the project partners – my own institution, the North East Wales Institute of Higher Education in Wrexham (NEWI) – has now taken responsibility for the further development and commercial exploitation of the software. Version 2 is due for release in July 1999. NEWI is also now the service provider for the interlibrary lending co-operative in Wales – Interlending Wales – which spans the various library sectors, with an emphasis on public and academic libraries. We intend to roll out SEREN as the software base for the future development of the Interlending Wales service over the next two years.

I'll describe the functionality of the software in terms of the experience of its users. The first stage is document discovery. SEREN uses a Z39.50 client to search any Z39.50 compliant databases – not just those of supplier libraries. The user can choose which catalogues or groups of catalogues to search. When the result set is returned the user selects the required item and the system then performs a search against the catalogues of supplier libraries. The process of identifying a required item is therefore separate from that of requesting it. This means that if the item is not available from a known supplier then it can automatically be requested from a backup supplier, for example the British Library Document Supply Centre.

Because of the way in which it is constructed, SEREN's Z39.50 client can be used as a general-purpose catalogue searching tool. It is based on the Europagate Z39.50 client but heavily adapted from the original. The major problem is in the variability of Z39.50 implementations at the target, and for optimum results we still need to have configuration file entries for each target.

The SEREN server assigns the request for an item to the supplying library. The request is packaged as a structured electronic mail message and transmitted to the supplier. The messaging protocol that SEREN uses is effectively a superset of the standard ILL protocol. The reason why SEREN uses extensions to the ILL protocol is that we need more complex handshaking for the purposes of the accounting records that SEREN keeps, and their reconciliation – that is, we record more status changes than the ILL protocol accommodates. We will be, however, investigating possible ways in which we can achieve greater compliance with the ILL protocol without compromising the functionality or integrity of the system.

The request is received at the supplying library and is handled by a software component known as the DSS (Document Supply Station). This is a Windows application which is effectively a specialised email client. This parses the request and displays it onscreen along with any other pending requests. A pick list can be printed so that the items can be retrieved from the shelves.

SEREN distinguishes between requests for physical items (for example books) and items which may be scanned and transmitted electronically. The software will record and account for the sending of a physical item through the postal system. Where an item is to be scanned and transmitted electronically, there is an extra stage. The software controls any TWAIN-compliant scanner via the TWAIN interface. The item supplier is prompted to scan each page in turn (if the page numbers are known) until the entire document is scanned. The documents are then encoded using the PNG graphics file format and sent as MIME attachments to the requester.

We use PNG because unlike JPEG it is a lossless compression format, though of course this limits the amount of compression that can be achieved. It is also open-source and unlike GIF, non-proprietary. A typical page of scanned text is likely to be 250K-300K in size, though pages with greater graphics content can be up to 500K.

The problems that we have encountered with using Internet mail as the transmission mechanism have largely been related to security mechanisms at individual sites. Typically a firewall might have to be reconfigured to allow the necessary traffic with the offsite server. We have also encountered problems with email virus checking software which unpacks MIME-encoded messages and repacks them with different boundary markers.

The email message containing the encoded attachment is received at the requesting site by the DRS (Document Receipt Station). At the DRS, the user prints the document and approves it as of appropriate quality. After approval, the electronic copy is deleted, for the purposes of copyright compliance. Full accounting records are kept by the system.

Although authorised end-usres may enter requests into the system via the Web interface, they must, with the current product, collect a physical item (printout or original) from their home library. This is for copyright rather than technical reasons - the ability exists in the design of the software to deliver documents to authorised end-users, by means of supplying the end-user with a URL for the document.

An initial aim of the project was to ensure that the product could be used by as wide a range of library services as possible, with minimal hardware and Internet connectivity requirements. It is perfectly possible to request and receive documents using a dial-up Internet connection, though only at very modest transaction volumes. Document suppliers would normally be expected to have permanent connections because of the volume of data that they would be transmitting. The minimum recommended specifications for the PC hardware and software are:

• Processor: Pentium 200 MHz or better
• Operating system: Windows 95/98, NT
• RAM: 16 MB (64 MB for Windows NT)
• Hard disk: 100MB free
• Display: VGA, 640x480, 256 colours
• Browser: Netscape 3 or higher, Internet Explorer 3 or higher
• Printer: 600dpi with 6MB RAM
• Scanner: TWAIN compliant

A POP3 Internet mail account is also required. Each module needs its own mailbox. Because of the file sizes involved, the receving mailbox needs to have plenty of disk space available.

The SEREN server is currently implemented on a P233 PC running Linux. Log files and the accounting system can require considerable disk space. Each SEREN community needs access to at least one SEREN server.

SEREN is designed for use with a co-operative or a group of libraries or information services that act as a community. That is, each requester is expected to be known to each supplier. Accounting in SEREN is based on this principle. The main effect of this is that the burden of authentication is lower and there is less need for a secure payment system. Any library may be a requester, supplier, or both. It is expected, for reconciliation of accounts, that there is a central co-ordinator but this is not strictly necessary: no one partner need have a privileged position. In practice, of course, someone has to operate the server (though this can be outsourced) and co-ordinate the partners.

In terms of system scalability the major limiting factor may the Z39.50 search. We have not carried out our own in-depth trials, nor have we encountered any particular difficulties in this area, but it has been suggested elsewhere that a reasonable upper limit on the number of concurrent Z39.50 searches is about 15. This can be overcome by sequencing searches but the constraint that will apply then is response time. There is, of course, likely to be an organisational limit to the size of effective co-operatives. However, it should be possible to link different SEREN communities together by common members, thus extending the "virtual" SEREN communities more widely.

SEREN was written from the beginning to be language-independent. That is, all the text in both the Windows and the Web-based software is read from tables and versions in different languages can be produced for the effort of translating the necessary text: no recoding is required. We already have the requirement for Welsh-language versions of the software, but we will also to be able to respond easily to any demand for versions of the software in other languages.

SEREN is at that stage in its development where it needs to progress from a funded project to an enterprise which can be self-sustaining. We know from the trials that have taken place that it is a robust and workable product. Cardiff University and the University of Wales College of Medicine are planning to extend its use across their campus libraries. Interlending Wales expects to roll it out to selected sites later this year. Naturally, we need critical mass to support its maintenance and further development and we are actively seeking new customers!

We expect that potential users of the software might include interlending co-operatives; regional library systems; multi-campus libraries; distributed library systems in multinational companies, governmental or quasi-governmental bodies. The Z39.50 client is in itself a strong product and might have uses in the construction of "distributed" union catalogues. There are still areas of functionality that need to be developed. For example, although the data collection functions of the accounting system are in place a full range of reports awaits development according to the needs of customers. We also hope to implement more sophisticated variable pricing mechanisms and algorithms for supplier choice: based, for example, on a combination of recorded speed of supply and cost per item.

SEREN is one of a number of products becoming available in the field of electronic document delivery. We believe it has some unique features and strengths, and that it can be a success both nationally and internationally.