Library Web Services

The conversion of the print card catalog to the online catalog has been the basic design model for current library products. However, patrons, with expectations shaped by Google and Amazon book recommendations, have been demanding more from the library web presence. And libraries, constrained by catalog vendor offerings, have struggled to advance their online visibility and capabilities.

With web services, however, libraries can draw on other libraries and organizations to enhance the patron experience.

The World Wide Web Consortium (W3C) defines a web service as a software system designed to support interoperable machine-to-machine interaction over a network. Web services are frequently just application programming interfaces (APIs) that can be accessed over the Internet.

Just as Z39.50 enabled the structured and automated exchange of catalog records among systems, web services enable the machine-to-machine transmission of many other types of useful information, such as book covers, book recommendations, and maps.

And just as reference librarians pull information together from many different sources to produce a final, combined report, developers can call upon multiple web services to produce what appears to be a single, unified library web page. In fact, most web pages already pull images and other content from several different locations; web services just extend this idea to pulling in software capabilities.

The underlying concept of web services is thus one of providing software services in a distributed computing environment. Be aware that web services also refers to one specific technology implementation (see sidebar). While this idea of exposing application interfaces for remote use has a long history in computing, the Internet has made the current scale of service possible.

Library web services explode catalog modules to make dynamic content available in catalogs and where patrons live online. For example, with existing library web services, you can get a list of ISBNs that match a particular book (OCLC's xISBN service or LibraryThing's functionally similar ThingISBN), install Amazon's SimilarityLookup, or find information from Talis on library branches that actually hold a copy. You can pull in all sorts of additional functionality that you may have neither the time nor the capability to develop locally.

Those using web services require some technical sophistication but often not much beyond what's needed to put together a complex web site. As consistent—and documented—sets of web services become more widely available, the barriers to use get lower all the time.

With its work building a library platform, for example, the UK-based Talis has created a set of interconnecting and documented web services suitable for use in enriching existing applications or in creating wholly new applications such as its proof of concept Project Cenote. Paul Miller, Talis senior manager and technology evangelist, says, “Web services offer all of us a long overdue opportunity to break apart the monolithic library system, permitting its reassembly from best-of-breed components drawn from across the industry.”

U.S. and UK developers have used the Talis Platform to make new catalog views available in quick order. Ross Singer, an LJ 2007 Mover & Shaker and a developer at Georgia Tech, says, “Overall, I'm really impressed with the Talis API. It is a lot easier to use than, say, Z39.50.”

The Talis Platform and the Talis Developer Network, its open development community, stand as the company's technical, social, and business vision of the future. Talis currently claims to serve about 25 percent of the library market in the UK but does not have products for sale in the United States.

LibraryThing provides another example of both a service provider and a service consumer. It also serves as a social center [see “Chief Thingamabrarian, LJ 1/07, p. 40–42]. It makes Z39.50 calls to search catalogs as necessary, can pull book cover images from Amazon and user-provided images, and, in turn, provides its own internal recommendation services for use by others [see “LibraryThing for Libraries,” p. 3].

This model lets libraries reach beyond their virtual walls to access capabilities that are not available from their own catalogs. For instance, in Denmark, when you do a search on Aarhus Public Library, a Danish catalog (see Link List), the results page is built by calling services running at other Danish libraries, including recommendations as well as links to book summaries and author portraits.

What is actually involved in incorporating a web service into your site? Take the simple example of adding a Google or Yahoo map. First, you must register for a unique “key” to identify your organization as the source of requests. The service providers thus can ensure that you abide by their Terms of Service; hence, you should ensure that your site and your use of their offerings match their requirements, which is usually to provide your URL and to stick within the prescribed usage limits.

To add a simple map, just have your web site designers add some JavaScript code to invoke the service. That's not much different from other ways in which they may already be using JavaScript to enhance your site. The providers' servers do the retrieval; the addition of a bit of “widget” JavaScript code provides new content.

Going beyond basic widgets, the Yahoo Pipes service provides a visual interface to combining various services. For example, the “New York Times thru Flickr” pipe takes a New York Times RSS feed, runs it through a Yahoo Content Analysis service, and uses the extracted keywords to locate related Flickr images. This kind of powerful remixing is enabled by providing data in a standard format, combined with simple, modular, standardized services.

Of course, you may be legitimately concerned that your web pages now depend on external services and content. This is an inevitable feature of the interconnected Internet world. To mitigate this risk, good programming practices, specifically in the areas of caching, error handling, and recovery, are essential.

Several resources may assist you in better understanding and planning for using web services and other Internet software services. The UKOLN briefing paper “Web 2.0: Addressing the Barriers to Implementation in a Library Context” (see Link List) examines several important considerations, including scalability, support, service longevity, and the possibility that some commercial organization may add advertisements or otherwise change their terms of service at a later date.

The Library Technology Report “Web Services and the Service-Oriented Architecture” by Marshall Breeding also gives a good conceptual overview and even a taste of some web services programming and functional code.

Libraries have always engaged their patrons and communities through services that reach outside the library walls as well as events within the building. Just as those activities bring patrons onsite to contribute collectively to the library community, a “Web 2.0” social library web site helps to enrich your online presence with user-contributed reviews, ratings, and commentary [see “Library 2.0,” LJ 9/1/06, p. 40–42].

As with traditional library community-building, technology-enabled outreach has both pieces. Web 2.0 is inward, bringing people into your web site. Web services reach outward, using your library services as a platform upon which people outside your organization can build.

No matter how large your organization, there is still greater innovation capacity outside your walls than within. You can tap into this reservoir of enthusiasm and talent by providing and publicizing web services access to patrons. This enables “superpatrons” with technology expertise to build new applications that use your library data, opening up access possibilities that you may never have imagined.

The tools, sites, and widgets that your technology-enabled community creates may in turn inspire a broader group of patron “tool users” to add connections to your library to their web environments. For instance, Library Lookup allows users to link to their library catalog page when browsing Amazon.

John Blyberg [see “Always Pushing Information,” p. 2–4] first put these ideas into place at Ann Arbor District Library, MI. On top of a traditional catalog, he built PatREST, an interface layer designed to help open up library data and services to patrons. With that foundational platform of web services in place, he has been able to provide nontraditional channels for accessing library services, including holds and items checked out in Google Gadgets.

Blyberg says, “It's safe to assume that we can never anticipate every need of every patron, so providing them with a set of simple tools to let them do what they want is a logical next step. PatREST aims to be just that. Its URI conventions and XML schema are designed to be easily understandable and easily parsed.”

Web services let your organization reach out to other libraries, enabling better technology tools for library interconnection, going beyond basic interlibrary loan (ILL) to more advanced types of search and data combination.

For example, OCLC's freely available Audience Level service allows you to pull popularity figures into your search results. As each library and organization adds more services to the “cloud” of available capabilities, the service platform available to everyone expands. Over time, a rich technology ecosystem will develop so that libraries can share data and services.

While at Cornell University Libraries, Karen Calhoun, now OCLC vice president for WorldCat and Metadata Services, was commissioned by the Library of Congress to provide provocative ideas about the future. Her report, The Changing Nature of the Catalog..., looks critically at current technology and processes.

“The next generation of [integrated library systems] will need to support the next generation of students, researchers, teachers, and scholars at our universities and colleges,” she writes, adding that “satisfying their needs will require modular ILSes that can be put together like Legos. Standards for connectivity and linking, like reference linking and web services, will be extremely important in making these loosely coupled systems interoperate.”

Web services provide an ideal technology platform for the interoperable distributed catalogs to come, both enabling intramodule interfaces as well as outward facing APIs. Opening the catalog up in this way allows reuse of its core services (e.g., book holdings) while integrating it with a much broader set of discovery tools. Web services would also be a sensible foundation for various types of resource sharing, such as enhanced ILL.

In fact, some catalog services may recede into the background, with web services providing infrastructure, and modern interface layers such as Ajax providing the user experience [see Andrew Pace's “Dismantling Integrated Library Systems,” LJ 2/1/04, p. 34–36]. This separation of functionality from presentation will be a key aspect of catalog modernization and modularity. As web technology continues to evolve, new types of display can be layered on without needing substantial alterations to core catalog services.

No library can afford to be an information island in the modern world. Resource sharing can extend beyond the exchange of books to the exchange of software. Just as sharing books enables many people to benefit from the same knowledge, sharing services enables many libraries to gain capabilities that otherwise would be out of reach. By consuming services and perhaps even developing your own, ideally all within the context of a larger library service–oriented architecture, libraries will be able collectively to provide their patrons with the rich web experiences they have come to expect.