Interlending in the Emerging Networked Environment: Implications for the ILL Protocol Standard (1995)

3. ILL SCENARIOS AND THE APPLICATION OF THE ILL PROTOCOL

The intent in preparing the scenarios has been to examine the communications requirements of interlending and document delivery activities, and relate these to the existing ILL protocol. During the course of developing the scenarios, several weaknesses in the ILL protocol have been revealed, which are addressed further below. The general conclusion, however, has been that the protocol offers sufficient functionality for most ILL communications scenarios.

3.1 Scenario 1: Document Supply Using Point to Point ILL: The “Canadian” Model

A description of the manual ILL system and its use of electronic communications forms a useful background for the scenarios described below. An ILL transaction starts when a patron determines that he or she needs an item that the home library cannot supply from its own resources and asks for the item to be supplied on interlibrary loan. How the patron determines the need for a document has normally not been within the scope of the ILL department, although other parts of the library, such as the reference service, would often be involved, either by making citations available in bibliographies or by conducting searches for the patron. Certainly the sources for citations were, and remain, widely varied.

In the manual system the patron normally fills in a form that is passed to the ILL office. As far as the patron is concerned, this is the end of the matter. Usually, in a few days or weeks, he or she is notified by mail or telephone that the item has arrived and that it is available for collection from the ILL office or the circulation desk.

Staff in the ILL office will normally have performed a number of tasks to ensure that the item arrives. They will:

• have verified that the item exists;
  
• have verified that the item is truly not available locally;
  
• have discovered one or more locations from which the item can be obtained;
  
• have sent a formal ILL request to the preferred location;
  
• they might have had a negative or conditional reply;
  
• they might have tried other locations.

All these tasks will probably have been tracked in one or more paper files maintained by ILL staff. These files are used to correlate incoming items with the requests that they filled; possibly to track outstanding requests, or items in use by patrons; to follow copyright restrictions and policies; to correlate incoming invoices with requests and verification that the items were received, etc. Each ILL office defines the nature, content and arrangement of these local files in accordance with local management, invoicing and audit policies.

Verification and location discovery use a variety of tools, both electronic and paper based. The tools include the local catalogue, union catalogues, national bibliographies, etc. Any or all might be available electronically. Multiple tools may be used to process any particular request, and a significant part of the skills used by ILL staff resides in the knowledge and experience that allow them to judge which tools to use when.

Items are supplied by the supplying library as either the physical item owned by the supplier or as a facsimile (generally a photocopy) of all or part of an item. In the first case the item is intended to be returned when the loan period is over; in the second, the facsimile is not intended to be returned to the supplier. In neither case does the library permanently acquire the item, although in the latter case the patron normally does get to keep the copy. The item is normally delivered to the ILL office, where it is correlated with the patron’s request, and from where the patron is notified that the item is available.

The ILL office tracks the loan of a returnable item, either through files maintained in the ILL office or through the library’s circulation system, and communicates as necessary with both the patron and the supplying library. The patron may request that a loan period be extended (a “renewal”); the supplying library might recall an item before the loan period was over; the supplying library might inform the requesting library that an item is now overdue, etc.

Figure 1 - Point-to-Point ILL (29K)

The simplest interlibrary communication in this scenario involves the transfer of a message containing some form of an ILL request from the requesting library to the supplying library, followed some time later by receipt of the item itself. Messaging for both the request and the delivery can be in many forms: surface mail, electronic facsimile transmission, even voice communication by telephone. The common factor in most of these technologies is that messaging is asynchronous: transmission of the message is separated from its receipt by an interval of time, often a large one. Delivery of the item is invariably handled separately from the request. It often uses a different channel or even technology: if the request is sent by mail, the item may be delivered by a courier service; if the request is sent by electronic mail, the item may be supplied by fax, etc.

As libraries have moved toward increasingly integrated automated systems, this scenario has remained a valid approach to handling ILL. Paper forms can be replaced with electronic ones, paper files with transaction databases, and paper messages with electronic communications, etc. Many libraries, however, have operational and audit requirements to retain a central ILL function. This provides their users with beneficial services in terms of discovering locations, negotiating costs and providing documents on time. It also provides the library with important benefits: control over its ILL use; feedback for acquisitions activities and policies; and optimal use of local collections. In a fully integrated requesting environment, we can expect to see electronic patron ILL request forms integrated with local citation databases in the OPAC. We can also expect ILL management systems with links to the local catalogue for verification, to electronic mail for messaging, to circulation for loan tracking and to financial management and accounting for invoicing and payment.

In addition, integration of requesting channels with delivery channels is becoming increasingly feasible. In a paper-based system, the delivery of a document is a separate activity from the request for its supply. To a large extent, this is remains true in current systems, even when either the request or the delivery is electronic. It will soon be possible, however, to create fully integrated document supply systems that receive an electronic request, process it as appropriate and then deliver the document using the required channel, e.g. electronic mail or file transfer, or possibly remote printing for fax delivery.

With electronic messaging, this scenario continues to form the primary Canadian model for ILL. In the Canadian environment, messaging has until recently been based on Envoy 100, the national public electronic mail service provided by Bell Canada. Envoy 100 has been available to libraries since the early 1980s and has been extensively adopted for ILL communication. It is a proprietary messaging system, accessible only via terminal connections using X.25. For this reason, there has been little incentive to integrate ILL messaging using Envoy 100 into other library systems, except by the largest users, such as the National Library of Canada and CISTI.

Both the National Library and CISTI have made use of the scripting facilities of Envoy 100 to provide on-line forms for requesting libraries to complete. The National Library’s interest in the use of on-line forms and the integration of ILL messaging into its internal systems led to its leading the development of a standardized protocol for ILL messaging. The protocol was initially developed nationally, and ultimately at the international level.

Sophistications of this scenario supported by the ILL protocol add additional messages, and require corresponding information to be recorded in local files. There may be responses from the supplying library to the original request: “cannot supply”; “placed on hold for later supply”; “conditions must be met”, etc. A conditional offer to lend requires a response from the original requester. The explicit or implicit interlibrary lending agreement between the two libraries may support supplementary ILL services, such as request cancellation; additional message exchanges will be required to invoke these services. Such additional messages do not need to be transferred using the same technology or channels as the original message.

The ILL protocol is expressly intended to accommodate the whole range of messaging needed to support this traditional ILL model. Services (i.e. message types) are available to:

• communicate with ILL partners to initiate the request (ILL Request);
  
• respond to a request (ILL Answer, with “Unfilled, “Retry”, “Conditional” “Hold Placed”, “Locations”, “Will Supply” and cost “Estimate” answers);
  
• reply to a conditional offer (“Conditional Reply”);
  
• cancel a request (Cancel and Cancellation Reply);
  
• indicate the item has been shipped and/or received (Shipped and Received);
  
• track the progress of a loan (Recall, Returned, Checked In, Overdue, Renew, Renew Answer); and
  
• report status and problems (Lost, Damaged, Status Query, Status or Error Report, Expiry, Message).

The protocol also allows a requesting system to manage messaging with multiple potential suppliers, or for a responder to forward a request to another potential supplier, with appropriate notification to the requester. Figure 2 illustrates the communications involved in managing messages with multiple responders for a single transaction.

Figure 2 - Point-to-Point ILL with Forwarding (37K)

The protocol does not, of course, require that all implementations support all these services. Implementations will support those services that are appropriate for the environment in which they operate. For a bare bones ILL requesting system, such as that illustrated in Figure 1, only the ILL Request service need be supported, together with a means of recording that a transaction has been terminated through an item having been received or sent. Most traditional ILL offices, however, would likely wish to have access to most of the message types described above as required for individual transactions.

By providing a standardized set of ILL services and regulating the sequence in which those services may be invoked (e.g. a Renew request may not be sent after a Recall request has been received), the protocol facilitates the development of automated systems for use in ILL messaging and management. Such systems can automate much ILL record-keeping by maintaining complete transaction databases of both ILL requests initiated and those received. Such databases could be used to satisfy audit requirements, legal reporting requirements, copyright restrictions, etc. In addition they could provide valuable input to selection and collection management activities. They could also be used to track the quality and timeliness of service provided by individual responders, correlate this with cost and lead to more accurate policy-based decisions on ILL partners for individual transactions.

There are issues of importance to ILL offices that the ILL protocol does not address. The two principal ones are billing and accounting and delivery of the document. Neither of these omissions is an oversight. Instead, the OSI application layer model on which the ILL standards are based suggests that messaging for billing purposes and for delivery should be the subject of separate protocols that are used in conjunction with ILL or other protocols (such as purchasing or payment) as appropriate.

The ILL protocol does, however, allow for the exchange of a rich set of information that allows the ILL transaction to be correlated to billing transactions and financial management systems as well as to the delivered item. The request can indicate whether and how much the patron or library is willing to pay; a separate billing address can be specified; an ILL request can be for cost estimates only; a responder may supply an estimate or make an offer to supply conditional on accepting an estimate. The data elements which would be required to interface ILL to an invoicing application or to integrate an invoicing standard into an ILL application are, to a large extent, already present in the data exchanged for ILL purposes. The request can also specify the delivery mechanism that is preferred, the delivery address, the required delivery time, etc.

3.2 Scenario 2: Document Supply Via an ILL Utility: The “U.S.A.” Model

A consequence of the development of large scale shared cataloguing systems such as OCLC, RLIN and ISM Library Information Services (formerly Utlas) was the creation of substantial union catalogues at those sites. Given the existence of these union catalogues, a further consequence was the demand to be able to use these resources for ILL requesting. The utilities’ response to these demands was to create centralized ILL facilities on their mainframe systems that enable ILL requests to be made for items found in the union catalogue.

These facilities are typically based on provision of a centralized mailbox facility with special features to support ILL messaging. To create an ILL request in such a system, a user—normally staff in the ILL department—searches the union catalogue to discover the required item, and invokes a command to create an ILL request for the item. An ILL screen displayed in response to the command displays information about the selected item, enables the requester to select one or more recipients of the request on the basis of libraries indicating they held the item, and allows the input of additional information such as journal article titles and pagination, patron’s name, supply-by date, preferred delivery mechanism, etc. When the user completes the request, the ILL system will automatically place the request message in each potential supplier’s mailbox in turn. Each supplier is expected to connect to the system on a regular basis to check incoming requests and to respond to these requests on a timely basis.

There is generally no mechanism for supporting off-line creation of requests or for delivery of messages to external mail systems; the user must connect to the utility to use the ILL facility.

Figure 3 - ILL via a Utility as Intermediary (53K)

In this scenario, as illustrated in Figure 3, the utility provides a single convenient point of access for the most labour-intensive parts of the ILL requesting process: verification, location discovery and request issuing. The utility may also take on the role of ILL agent, whereby the utility manages interactions with a set of potential responders (a “send to list”), communicating with each in turn until one responder undertakes to supply the requested item.

The use of an ILL utility replaces most of the variety of messaging channels described for the point-to-point scenario with a single channel—messaging managed by the ILL utility. Many libraries will, of course, continue to require access to the other channels for some portion of their ILL messaging: for libraries that are not subscribers to or members of the utility; for urgent requests in which the turn-round time in the utility’s mailbox is too long, etc. The single channel does, however, simplify matters for the requesting library considerably. Much of ILL work can now be done by accessing the single system.

Note, however, that this access has been, and predominantly remains, terminal based—the utility provides a remote mailbox facility to which users must connect at regular intervals to check mail; mail is not sent directly to users’ systems. Neither does the utility normally maintain a database of ILL transactions. An implication of this is that local records of transactions, often in the form of prints of the utility’s mail screens, have to be kept in addition to the transactions that are maintained at the utility.

Furthermore, however large the utilities’ union catalogues become, none will ever be fully comprehensive or global and there will be a continuing need to be able to send requests to other sources not available through the utility or to be able to try multiple utilities.

It should also be noted that use of the utilities’ ILL requesting systems still only addresses part of the complete document supply problem - the initial request and its response. Physical or electronic delivery of documents, tracking of items during the loan period, invoicing and payment are all outside the scope of these systems, and other channels and management systems continue to be required to complete the transaction as well as to maintain local management and audit information and to issue, verify and pay invoices. The use of the utilities has not, therefore, significantly eased the paper burden of transaction management in ILL offices.

The ILL protocol addresses this scenario, and provides mechanisms for improving the services offered by utilities through its support for the ILL intermediary role. The standard defines three basic types of ILL transaction, simple, partitioned and chained. The point to point scenario described above corresponds to the simple transaction, and the use of a utility as intermediary in the present scenario corresponds to the partitioned transaction.

The chained transaction corresponds to the operation of some centralized ILL agencies such as the British Library Document Supply Centre, where not only requests, but also documents themselves are routed via the agency. This is discussed further below.

In the partitioned transaction, which corresponds to the approach historically taken by North American bibliographic utilities, there are at least three participants in any ILL transaction:

• the requester (the ILL department issuing the request),
  
• an intermediary (the utility), and
  
• one or more responders (partner libraries) to whom the request is addressed by the utility.

The ILL request is created by the requester and passed to the intermediary, and the intermediary passes the request on to individual potential responders in turn until an actual responder is found. The intermediary then responds to the requester. After the desired item has been shipped—directly from the responder to the requester—and the responder has notified the utility that the request has been satisfied, all further transactions take place directly between the requester and the responder; the intermediary’s participation ends when a responder has been found.

Figure 4 - ILL requests passed to other utilities (11K)

Note that the standard also permits multiple intermediaries to be involved. This could permit, for instance, one utility to send a request to another utility when no responder has been found by the first utility, as illustrated in Figure 4. This illustrates a request passed from a library to a utility, which communicates with its potential suppliers in an unsuccessful attempt to fill the request. The utility then forwards the request to a partner utility, which in turn communicates with its suppliers. One willing supplier is found that delivers the document to the original requester.

Forwarding by intermediaries could also enable hierarchies of ILL utilities to be established, in which regional utilities attempt to satisfy a request before passing the request on to a more general national utility or to other nearby regions.

The requester specifies in the request whether partitioning is permitted (although obviously a request directed to a utility would have to permit partitioning), and can include a send to list of potential responders. The request can also contain a list of responders that have already been unsuccessfully tried.

3.3 Scenario 3: Patron Initiated ILL

However, this causes an operational problem for libraries, and especially for the ILL office. When a patron discovers a relevant item he or she will want it, and will want to be able to order it easily, for example by pressing a button or issuing a command while connected to the utility’s database, just as the ILL staff member does. The typical ILL office, however, is not set up to support this approach very well. Often the patron will have to write down or, in some environments, print the citation and take it to the ILL office. There, staff will do the usual processing of the request, which will often lead to their connecting to the utility, searching the item and issuing the request. But the patron has already done most of this; why ask the overworked ILL staff to do it all again?

There are conflicting requirements here. The patron wishes to request supply of an item that is needed, and wishes to do this as effortlessly as possible. The library has an obligation to ensure both that use of local resources is maximized and that ILL is used as little and as cheaply as possible. The patron doesn’t want to have to look in more than one place to find an item. The library will normally want to be sure that a requested item is not available locally before requesting it from a remote supplier. The patron does not normally care who supplies an item. The library does, because some sources are more expensive than others, or take longer to supply the item, or have more restrictive policies.

The requirements to be met, therefore, are to:

• allow the patron to request an item easily while searching the utility’s databases, while at the same time
  
• allow the library to retain control over the issuing and processing of the ILL request.

There are two approaches to meeting this requirement, described in the sections that follow.

3.3.1 Scenario 3A: Library as Requester: OCLC Model

In this model, the utility sends a message to the patron’s home library saying, in effect, “We have been asked by your patron Jane Doe to get item ABC on ILL. Do you approve?”. The library accepts or rejects the proposed ILL, using whatever procedures it determines are required. This might include checking the local catalogue for availability. The library might make other changes to the patron’s request, such as specifying or changing a send to list or indicating a cost limit. The library could process the request either through staff action, as in traditional ILL, or by automated means. This latter might include automatic lookup in the circulation database and the patron database to determine availability and what the patron’s status and account balance are, etc.

Figure 5 - Direct Patron Requesting: Utility Manages Transaction (43K)

This approach, illustrated in Figure 5, is currently being implemented by OCLC in its patron request system, although without use of the ILL protocol.

The ILL protocol does not at present support this approach. The standard requires that all transactions must be initiated by the “requester”, the recipient of the document. If the patron’s home library is to be the formal requester, that is, is to assume responsibility for a loan initiated directly by the patron at a utility, then the home library must be able to record the fact of the transaction, and also to accept or refuse liability for the return of (or payment for) the item.

Additional protocol services will have to be defined to support this requirement. The additional services required would be some form of an “ILL Approve Request” service invoked by the utility (the intermediary) to propose creation of an ILL transaction and possibly an “ILL Approve Answer” service invoked by the patron’s library to accept or reject the proposed transaction. Alternatively an answer could be in the form of an ILL Request message or Cancel message as appropriate.

This approach has the advantage that it allows the utilities’ existing terminal based search and ILL requesting facilities to be used by patrons, and, depending on the level of automated support desired, relatively little additional development effort would be required to implement the additional ILL services as part of an ILL application in the library.

3.3.2 Scenario 3B: Library as Intermediary: FCLA Model

In order to implement this approach satisfactorily, the local element of the search interface will have be largely transparent to the patron, so that the patron merely issues the command to request an item, and the system does the rest of the work. Where the patron is using the library’s system to search the utility, development of such an interface is relatively straightforward, and the simple model of the library as requester as described in scenario 2 would still apply.

Increasingly, however, the patron will not be using the library’s system to search the utility, but will be using a search client application on a personal computer or workstation. This makes the design of the application significantly more complex, since the user’s application will have to manage communication with both the search target and the patron’s library. Using data from the search result, the desktop application will have to generate a request to send to the home library’s ILL system. These requests could then be used to generate ILL protocol transactions in the library’s ILL requesting system.

There is no requirement that the messaging between the patron’s system and the library’s ILL system be protocol based. One possible implementation could be to use the Z39.50 Item Order service to communicate requests between the patron and his or her library. This is described further in section 4 below.

A fully protocol-based approach would be to model the patron’s system to act as the ILL requester, with the library’s ILL system acting as the chaining intermediary to manage separate transactions for the patron request and the request sent to the utility. Using the protocol allows standard ILL messages to be exchanged between the patron’s system and the library’s ILL office. This offers the advantage that notification of difficulties in obtaining the item or messages during the course of a loan, such as a recall, can be passed to the patron, without the need for a separate messaging mechanism.

Figure 6 - Direct patron requesting: library manages transaction (13K)

The ILL standard fully supports this approach as illustrated in Figure 6. With the ILL office as a chaining intermediary, all messages relating to the transaction are passed through the ILL office—there is no direct interaction between the patron and the library supplying the item. Depending on the policies of both the responding and the patron’s home library (formally the intermediary), requested items might be delivered directly to the patron (for example, photocopies might be mailed directly to the patron). Otherwise they could be delivered via the ILL office (items on loan might be delivered only to the patron’s library).

In the ILL protocol a chaining intermediary does not take an active role in the tracking phase of a loan; it merely acts as a relay for messages such as overdue, renew, recall, etc. If the patron’s library wishes to take an active part in managing loans, then it can use a different protocol mechanism to manage distinct ILL transactions, in which it has one transaction with the patron, and a separate ILL transaction with the utility. It would act as the ILL responder in the transaction with the patron and as the ILL requester in the transaction with the utility. This permits the library to take an active part in managing the loan, such as recording the loan in the local circulation system so that overdue notices can be issued, fines levied, etc.

While the ILL standard supports both these models, implementing either of them may require substantial development effort on the part of libraries or their system vendors to create desktop requesting applications. These applications will have to search the utilities and, from records retrieved, create ILL messages to send to the local ILL office. Such systems will debar patrons who have only terminal access to the utility from using the ILL requesting facilities currently provided by the utilities; they would have to resort to printing a citation and taking it to the ILL office. These difficulties are such that this approach is likely to be feasible only in a client server searching environment, such as that provided by use of the Z39.50 protocol.

3.4 Scenario 4: Document Supply Based on ILL with Circulation Knowledge

The connectivity explosion of the past several years, however, is beginning to make circulation information at individual libraries readily available through remote access to library catalogues. Clearly, patrons, as well as library staff, will increasingly wish to make use of circulation information in ILL requesting. The challenge for software vendors and system designers lies in integrating union catalogue access with circulation lookup and document requesting into a coherent system that satisfies the needs of both patrons and library management.

In the longer term, applications will have to be developed that provide a single user interface for searching and document requesting. The scenarios below describe two possible models for creating such applications.

3.4.1 Scenario 4A: Requester Checks Status

Figure 7 - Requesting Library Checks Availability (15K)

ILL requests are sent directly to the supplying library, which is chosen on the basis of knowing the availability of the item at all the potential responders. Normally only a single ILL request will be sent, since lending policy and availability is known at the time of making the request. Alternatively, ILL requests could be routed via a utility to allow the utility to provide value-added services, such as centralized billing. Even here, however, only a single sub-transaction will normally be created, since a positive response to the request is expected.

It is assumed that the maintenance of a centralized database of circulation statuses is neither desirable nor technically feasible. The thrust of library systems is increasingly towards keeping this kind of transaction information local. Determining circulation status will therefore require searching individual circulation systems. They could be searched sequentially, in some order determined by the requester, or they could be searched simultaneously. The first approach would allow the requesting library (or ILL system vendor) to develop algorithms that minimize ILL costs by maximizing load balancing or by ensuring the cheapest and/or nearest sources were tried first. The second approach would permit the user to be shown a display of available copies from which he or she could choose freely.

3.4.2 Scenario 4B: Utility Checks Circulation Status

This model does, however, require the utility to carry out the circulation status checking required to make informed ILL decisions. This implies, further, that the utility will have to move from being a relatively passive recipient of messages in the communication network to actively initiating connections with member libraries in order to initiate and manage document requesting activities. The consequences of this for telecommunications management at the utility could be profound. It also requires that the utilities maintain large databases of ILL transaction information. The cost of meeting these two requirements may prove to be prohibitive for the utilities.

Figure 8 - ILL with Locations: Intermediary Manages Transactions (31K)

In this model, illustrated in Figure 8, the user (again, either patron or ILL department) performs a search of the utility’s union catalogue, and, having found an item of interest, indicates that it is to be the subject of an ILL request. This request is sent by the user’s system to the home library, which performs another search, asking for availability for a given item. The utility performs Z39.50 searches at some or all of the locations for the item and displays the availability results for the user to create a send to list. The utility then sends an ILL request to the selected location. This request may be either an ILL protocol message sent via electronic mail, or since the Z39.50 connection is already open, an ILL protocol message transmitted using the item order extended service of Z39.50.

Note that because this model implements services at the utility, relatively simple end-user systems can be supported. Access could be provided via Z39.50 client systems on workstations, but also via terminal access to the utility using the highly developed communications networks currently supported by the utilities.

3.5 Scenario 5: Reciprocal Borrowing

The patron approaches the circulation desk in a “foreign” library with a book that he wants to borrow. The circulation clerk wands the patron’s library card and the bar code in the book; the system says it will take a few moments to authorize the transaction. After a short delay (equivalent to the delay at a bank ATM) the transaction is approved, the book is checked out in the normal way and the patron leaves with it. When he is finished with the book, the patron may return it to his home library or to the foreign library he borrowed it from.

There are two general strategies for implementing support for reciprocal borrowing in an automated environment, the “resource sharing” or ILL strategy, and the “patron sharing” strategy. Which is chosen by particular consortium depends to a large extent on the financial and contractual obligations that libraries enter into when establishing reciprocal borrowing.

3.5.1 Scenario 5A: Reciprocal Borrowing as Resource Sharing

Figure 9 - Reciprocal Borrowing as Resource Sharing (20K)

Modeling reciprocal borrowing as an ILL protocol transaction implies that the patron’s home library accepts responsibility for the return of the item. The patron is answerable only to his or her home library, irrespective of where the loan was actually made. Fines and charges, therefore, will be levied by and will be paid to the home library.

Exactly the same ILL services are used in this scenario as in scenario 3a. The difference is that now, rather than the patron initiating the request, the “responding” (i.e. foreign) library’s circulation system is communicating with the “requesting” (i.e. home) library’s ILL system to initiate an ILL transaction. Because of this, real time responses will be required. The whole sequence of communication can be transparent to both the user and the circulation clerk.

The sequence of services used in this scenario is shown in Figure 9. The attempt to charge out the item to a non-local patron will result in an ILL-Approve Request protocol message being sent to the patron’s home library. This will be answered with an ILL-Approve Answer message, either positive or negative. If the answer is negative, the patron will be told that he or she cannot borrow the item. If the answer is positive, the item will be charged out in the library’s circulation system, and an ILL Shipped message will be sent to the patron’s home library to record the state of the transaction. Note that in the lending library’s circulation system the item is recorded as being on loan to the requesting library, and not on loan to the patron. When the item is returned, the library checks the item in and sends an ILL Checked-in message to the patron’s library to terminate the transaction.

One benefit of this approach is that patron information is never distributed beyond the patron’s home library; as far as the other consortium’s members are concerned, all transactions are between libraries, as in traditional ILL.

As discussed under scenario 3a, the ILL protocol does not at present fully support this model. Additional services will be required to allow the lending library to initiate an ILL request and to allow the patron’s home library to respond appropriately.

3.5.2 Scenario 5B: Reciprocal Borrowing as Patron Sharing

Here it is not physical items that are being shared amongst consortium members, but information about patrons. This is in fact fairly straightforward to implement using existing protocols, since only a search to obtain patron information is involved. The Z39.50 protocol can easily accommodate this kind of remote patron lookup, with transfer of a standardized patron record. It is important to note that the ILL protocol has no part to play in this scenario. Figure 10 illustrates the communications involved in the patron-sharing approach to reciprocal borrowing. It should be noted that the apparently identical communication activities are implemented by very different protocol messages and result in the transfer of very different data.

Additional facilities may be required to inform the patron’s home library of any delinquency on the part of the patron, and further facilities would be needed if the home library requires notification of every circulation transaction involving its patrons. If the latter is truly a requirement, the ILL model of reciprocal borrowing would seem to be more appropriate. Notification of delinquency could probably be most efficiently handled by mechanisms involving (automatic) generation of electronic mail messages to the home library, where they would be used to update the patron file with the delinquency information. The home library would not have to notify the patron of an item becoming overdue, etc., since this is handled by the foreign library.

Figure 10 - Reciprocal borrowing as Patron Sharing (18K)

Since this model involves the exchange of personal information, there is a greater need for secure communications here than in any of the ILL based scenarios.

3.6 Scenario 6: Commercial Document Supply

A common commercial arrangement at present is for a utility, such as OCLC, to act as a “retailer” for documents supplied by one or more “wholesalers”. In this arrangement the requester (a patron or library) searches citation databases made available by the utility, and, when using a terminal connection, can invoke the “order” option for any item or items found. Some systems that provide documents from more than one supplier (for example OCLC) will respond by showing all the sources that supply the item and what the prices are and require the user to choose the preferred supplier. The retailer will obtain billing information, such as an individual user’s credit card number, if necessary, and will send an order message, using a proprietary protocol or an EDI standard such as the X12 purchase order, to the supplier’s system. The supplier normally sends a photocopy or fax of the item directly to the user.

This corresponds very closely to the partitioned model of ILL, although there are a few significant differences. Most important is the requirement for the intermediary to respond to the request with a list of possible suppliers and costs. Although the ILL protocol supports the sending of a cost estimate in response to an ILL request, this answer terminates the transaction, which is not the case in the document supply scenario. An ILL conditional answer could be used, since this requires a response, and the pricing information could be included in a responder specific results parameter. The protocol’s Conditional answer message, however, contains only the single Yes/No; there is no mechanism to include responder specific information. Such a mechanism would have to be developed to enable the ILL protocol to support this approach. This would require an additional message type, or the addition of parameters to the ILL conditional answer. One approach could be to specify a new type of ILL-Answer, an “Options” answer. This would contain all the options and allow the user to choose one.

Another option when using Z39.50 for search access would be to use a Z39.50 search to retrieve supplier information relating to a specific item (such as a search directed at the logical “Current Prices” database), and only issue the ILL request (probably as a Z39.50 Item Order) once pricing information for the item has been received. This, however, requires close integration of the two protocols and careful user interface design in order to replicate the functionality of the current terminal-based systems.