A long-standing model of interlibrary loan involves a centralized service that brokers requests among very large groups of libraries. OCLC stands as the best-known and largest organization providing this type of service. In previous times, several other services existed, including UTLAS in Canada, Western Library Network (WLN) based in Washington, and Research Libraries Information Network (RLIN), but considerable consolidation has transpired over the last two decades. WLN and RLIN have become part of OCLC, and the former UTLAS services have been subsumed within Auto-Graphics. Many national libraries, including those of Australia, New Zealand, and most countries in Europe, operate centralized interlibrary loan services. Others, such as CISTI in Canada, Docline, operated by the National Library of Medicine, and the British Library, operate large-scale document delivery services.

Centralized interlibrary loan services are often tied to bibliographic services, such as the maintenance of a comprehensive bibliographic database that provides MARC records in support of original and copy cataloging. As part of the bibliographic services, either through online cataloging or through batch processes, holdings data is associated with the MARC records in support of related services, including interlibrary loan.

These monolithic interlibrary loan services play an essential role in the global enterprise of resource sharing. Almost any desired item, no matter how obscure or rare, can be provided through one of these services. OCLC’s WorldCat, for example, aggregates metadata describing massive amounts of material available on request.

The main disadvantages of this model of interlibrary loan involve high expense and relatively long times to fulfill requests. Costs might include transaction fees assessed by the interlibrary loan service broker, charges assessed by the lender, and shipping. A request might cycle through multiple potential suppliers before it is completed, and shipping from distant locations will extend the fulfillment interval even further. Yet for materials that cannot be supplied in other ways, these services play a vital role.

Some of the technology issues related to these centralized interlibrary loan systems include the standards, pragmatic protocols, application programming interfaces (APIs), and other techniques for automated submission, tracking, and monitoring of requests and workflow tools that streamline the business processes associated with submission and fulfillment of requests.

Libraries also engage in other arrangements that can satisfy at least some percentage of their patrons’ needs at lower costs and with faster fulfillment than a monolithic interlibrary loan service. By banding together in consortia, libraries are able to pool their resources to gain various benefits. The ability to draw from materials distributed across a larger group of libraries can significantly increase the size of the collection effectively available to patrons and reduce the number of requests made to higher-cost services. While these consortial groupings do not offer the comprehensive level of resources available globally, they establish a pool of resources far greater than any of the participating libraries would hold individually. Rather than rely on the postal service or commercial shipping, consortia often implement a courier service that makes regular rounds among the participating facilities.

These consortial resource-sharing organizations depend on some type of technology infrastructure. As shown below, models include sharing an integrated library system or using add-on software that provides discovery and request management in conjunction with multiple integrated library systems that may be in place in the participating institutions.

One of the challenges in resource sharing relates to the different technology platforms involved. An interlibrary loan system relies on a large-scale business application that manages the metadata of available resources, routes requests for materials, and performs a myriad of other activities in support of its operations. Libraries use the circulation module of their integrated library system to manage their inventory of materials and associated lending activities to their own users. The separate operation of these two independent systems can impose a great deal of duplicative work for the users in need of materials, for the interlibrary loan personnel involved, and even for the underlying computer systems.

Finding ways for requests to automatically flow among interlibrary loan systems and integrated library systems is one of the great technology challenges to be solved. International standards, such as ISO ILL or other agreed-upon techniques for the exchange of request transactions between systems and NCIP or SIP for communicating with a circulation module of an ILS, and the use of APIs are part of the toolkit of components available for the construction of a technology environment that can knit systems together seamlessly.

Cooperative arrangements for resource sharing ideally distribute the workload evenly among participants. Whether a library is a net lender or a net borrower will depend on the relative strength of its collections and the research needs of its patrons. It’s also important not to overburden any library disproportionately. The business logic of any resource-sharing or interlibrary loan system needs to be programmed to select potential lenders in ways that balance the load.

Efficient resource sharing involves establishing networks of trusted systems in support of the cooperative agreements among institutions. Reciprocal borrowing arrangements establish the general principle that a given set of libraries agree to allow their patrons to borrow materials from each other’s collections. The implementation of these agreements requires some supporting technical infrastructure. There are various approaches possible, including those that rely on applications that enable groups of libraries with separate ILS implementations to communicate with each other in support of reciprocal borrowing and others that might involve participating in a shared ILS that can both provide standard automation support for the libraries and facilitate resource sharing. The ability to route requests automatically between peer-to-peer resource-sharing networks or to pass unfulfilled requests to centralized ILL services also involves extending that trusted network to external systems.

An ILS shared by a library system provides a shared automation and discovery environment for a group of libraries within the same organization. These libraries operate under a common governance and funding structure. Examples include countywide library systems, library districts, multibranch municipal libraries, and even statewide or national systems. Materials in these shared systems are routinely circulated among all the facilities.

One of the key features related to sharing resources within these types of systems involves the ability to easily transfer items among branches. This capability enables patrons to request and receive materials housed at any facility within the system at the branch most convenient for their use. Traditionally, materials are assigned to specific branches or facilities, and materials delivered to a borrower at another branch are returned to the owning location. Another arrangement allows collection items to float, with items remaining at the branch to which they are returned even if they were originally assigned to another facility. Some libraries implementing floating collections create a layer of business rules that would identify specific items designated to be returned to their home location or that would control overall volume transfers so that the net gain or loss in the total number of materials in any given branch remains within designated thresholds.¹

The circulation modules of most integrated library systems support floating collections. Some of the products that include this capability are VTLS Virtua, Millennium from Innovative Interfaces, Library.Solution from The Library Corporation, Polaris from Polaris Library Systems, SirsiDynix Symphony, and SirsiDynix Horizon.

Many consortia bring together groups of libraries that each operates its own integrated library system. Efficient reciprocal borrowing among libraries with separate integrated library systems requires the implementation of an additional layer of technical infrastructure. This infrastructure would have a variety of components, including a union catalog that spans the collections of the participating libraries, a request management system, and connectors to the ILS of each of the participating libraries.

The basic resource-sharing scenario is to enable a patron to search the collective holdings of the entire consortium, request an item from any of the participating libraries, and have that item delivered to the patron’s home library for pickup. While that workflow may be built in to many multibranch ILSs for a single library system, it is more difficult to achieve when multiple ILS implementations are involved, especially a mix of different ILS products.

The union catalog component of the consortial resource-sharing environment can be implemented in different ways. A physical union catalog would consist of a bibliographic database populated with the holdings of each of the participating libraries. The MARC records would be extracted from each ILS instance and loaded into the union catalog system at some periodic interval, maintaining data regarding which library holds each item. Regular ongoing synchronization between the union catalog and local systems is needed to keep data current.

Another option involves using federated search technology, usually based on the Z39.50 protocol, to create a virtual union catalog. Under this approach, the queries entered by patrons would be broadcast to each of the ILS implementations to dynamically identify materials available within the consortium and the owning library. The virtual union catalog approach avoids the overhead of loading and synchronizing MARC records, but it may have limitations in performance and scale.

The consortial resource-sharing system would also include a request management system. Some of its capabilities would include accepting requests via the union catalog or other means, routing the request between ILS implementations of the owning and borrowing libraries, and performing various tracking and management functions. The process is based on using the existing functionality of the circulation module of the ILS to allow a remote borrower to place a hold on an item, which would then be routed to the designated library in the same way as any other local pickup location. The home ILS of the patron likewise exercises the circulation functionality that applies to notifying the patron that the item is available and charging the item to the patron for the specified loan period. The core problem is that the ILS of the library owning the desired item will not have a record for individual patrons of the partner libraries, and the ILS of the borrower’s library will not have a bibliographic or holdings record for the requested item. These problems are solved through a series of commands executed by the request management system, using the NISO Circulation Interchange Protocol (NCIP). The sequence would include some variation of these actions:

• A patron associated with Library A places a request for an item in Library B.
• The patron is authenticated as a valid patron eligible to make the request using the patron barcode number and PIN in the ILS of Library A.
• A temporary patron is created on the ILS of Library B.
• A hold transaction is submitted for the item record in Library B and the temporary patron record, specifying the desired pickup location in Library A.
• A temporary item record is created in the ILS of Library A.
• A hold transaction is generated for the patron in Library A against the new temporary item record.
• The circulation module of Library B includes the item in its routine list of materials to be pulled for hold requests.
• The item is physically routed from Library B to Library A.
• Library A receives the item.
• The circulation module of Library A generates a hold notice to the patron indicating the item is available, and it is placed on the hold shelf of the designated branch.
• The item is checked out to the patron using normal circulation procedures, based on pre-established loan rules for loan interval, renewals, and fines.
• The item is returned by the patron and discharged on the ILS of Library A.
• A message is generated to route the item back to Library B.
• Library B receives the item.
• The temporary item and patron records are removed.
• Selected data regarding the transaction is logged for statistical reporting.

While this sequence of actions seems complex and fragile, it can be entirely automated by the request management application and allows the library to handle these consortial loans using the same system and procedures that apply for the circulation of its own materials. Depending on the efficiency of the courier service among the libraries in the consortium, this model of consortial borrowing can make materials available to patrons in times similar to local hold requests. Fulfilling requests in this way is much less expensive than relying exclusively on external interlibrary loan services. Only those requested items not available in any library in the consortium would need to be processed through an external interlibrary loan request. The consortial request management system might optionally have the capability to automatically route such requests using the ISO ILL protocol, an API, or other system-to-system interchange method.

A consortium of libraries of independent funding and governance might also join together to participate in a shared integrated library system. Such an arrangement comes with complications beyond an ILS shared among the branches of a library system but avoids the complexities seen above in managing transactions among the circulation modules of multiple ILS implementations. In a consortium, the libraries may have different policies, priorities, and organizational concerns, which all have implications for the shared ILS. Some of the issues that potentially apply to a consortially shared ILS include these:

• Different libraries may have different circulation policies for materials, such as loan periods and fines assessed.
• The interests of participating libraries in emphasizing their branding and identity in online catalog search and display pages may conflict.
• The funding model for an automation environment shared by independent libraries varies, but usually involves distributing costs among participants according to a formula that includes factors such as service population, size of geographic service area, size of collection, or other variables. In some cases, the consortium may be funded centrally by a state agency or other sponsor.
• Materials may be owned by the individual libraries. Though available for borrowing by patrons affiliated with any library in the consortium, returned materials must be routed to the owning facility.
• An ILS shared within a consortium may also include multibranch libraries. The loan rules and other policies for how materials circulate within these groups may be different from those for the overall consortium.

A shared ILS provides opportunities for libraries to gain benefits not just in resource sharing, but also in lowering their overall automation costs. The costs of participating in a shared ILS in almost all cases will be less than the library operating its own implementation. The total expense of operating the system, including the costs for the ILS software and maintenance, hardware, and technical and administrative personnel, can be distributed among consortial participants. A shared ILS also avoids the expense of the add-on consortial borrowing infrastructure. A consortially shared ILS also provides opportunities for other services, such as centralized acquisitions and cataloging. According to Leon and Kress, the cost per transaction in this model averages $3.88, versus $12.11 for traditional interlibrary loan transactions.²

Participating in a shared ILS raises various issues of policy and practice. The participating members may elect to adopt a simplified set of circulation policies for loan periods, numbers of allowed renewals, fines, and other operational parameters. A shared ILS, however, would allow each library to maintain separate policies as needed.

An ILS shared by a consortium provides inherent resource-sharing capabilities. Through the use of common automation infrastructure with a comprehensive database that spans the materials of all the collection members, patrons have access to a large aggregate collection, a much larger pool of materials than any member library could offer individually.

One of the key features of such a consortially shared ILS involves allowing patrons to request materials, either from their own local library or any other library in the consortium, through a simple hold operation as provided through the online catalog and circulation modules. Placing a hold triggers a message to the home library of the item, which is pulled and routed to the requesting library. By using the built-in capabilities of the circulation system, fulfilling a request is inexpensive and fast, depending on the efficiencies of the consortium’s courier service among its members.

These ILS implementations shared within a consortium can serve a large number of libraries. One of the ongoing trends involves continual expansion of the size of these shared ILS consortia, often through the consolidation resulting from the mergers of previously separate consortia. In the current era of infinitely scalable computing platforms, the number of libraries that can reasonably share the common infrastructure of an ILS may be virtually unlimited. Ambitions for statewide or national automation infrastructure may be within grasp.