Online accessibility of metadata and full text content has resulted in a fundamental change in user expectations and a concomitant adjustment in library collection-building principles.¹ As users discover globally distributed content and grow to expect instantaneous access, libraries are transitioning from limited “just-in-case” local collections to “just-in-time” access to a wider range of content. This shift toward access over ownership has profound implications for OpenURL linking functionality.

OpenURL resolvers were originally designed to ask this question: Does my library own this item, and, if so, how do I obtain it? The shift toward an expectation of instantaneous access and away from ownership changes the question to these: How do I get this item? And how long will it take for me to do so? Resolver menus have already adapted to this change to some degree by linking to Google and interlibrary loan or document delivery, but further change is needed to meet user expectations more effectively.

Ideally, instead of listing services through which an item can be acquired, resolver menus should indicate the delivery time for each available format. For example, instead of advising users, “Request this article via Interlibrary Loan,” they should read, “Deliver this article in three days or less,” as appropriate. Also, in keeping with an instantaneous, access-based approach, resolvers should be configured to support unmediated pay-per-view access to appropriate journal article collections whenever this service can be offered.² The ideal resolver menu for books would search locally available catalogs and present holdings, availability, and delivery information as well as interlibrary loan request links, where appropriate. Libraries participating in patron-driven print book acquisitions or with print-on-demand book machines could bring these options to the resolver as well.³

An increasing amount of research and scholarly work depends on communication in alternate formats. These range from conference proceedings and datasets, to audio and visual files, even to administrative and other nonscholarly content. The structure of the OpenURL standard is inherently flexible enough to accommodate these formats, but the resolver knowledge base is not. This suggests a general principle that should guide the future of OpenURL: use only when necessary.⁴ In other words, OpenURL should be applied only to situations and content types that experience the appropriate copy problem.⁵ When a static link or even a specific Web search will do, it is often preferable. The appropriate copy problem does not exist for content that is available in only one place (e.g., datasets) or content that is freely available to all and therefore appropriate for all. Practical reasons, however, tend to drive the use of OpenURL for freely available and other less apposite content: it is currently the only hook into proprietary source databases that libraries can control.

Libraries face a growing appropriate copy problem due to the wide variety of platforms that host electronic books. One simple improvement is to ensure that our e-book provider platforms are made to be OpenURL-compliant sources. Source OpenURL functionality is arguably more important for e-book platforms than for e-journal platforms because, unlike for journal content, e-book restrictions and usability issues often drive users to want to borrow or buy a print copy. Furthermore, OpenURL is necessary to enable easy navigation from a digital-rights-restricted copy of a book (e.g., partial access, no download, or limited printing) to a version with no DRM restrictions (i.e., on the publisher's site). As of this writing, the only one of the “Big Five” e-book platforms used in libraries that supports OpenURL is Google Books, via its “Find in a library” link to OCLC's Worldcat.org.⁶

E-books present some unique challenges for OpenURL resolver knowledge bases and vendors. Because most books are not serial publications, they have to be represented at the individual book level. Thus there are roughly two orders of magnitude more potential book records than serial records (approximately 20 million books versus 200,000 journal titles).⁷ Although books have standard numbers assigned to them as journals do, books often have several ISBNs assigned to different physical and electronic manifestations of the same work, where journals only have one commonly used, comprehensive identifier (print ISSN). OCLC's xISBN has the potential to be a major help here, but the challenge of deciding the appropriate level of distinction between intellectual works is not easy to solve. This next phase of knowledge base building is necessary though, and differs from the first phase in that it is taking place after library link integration into Google Books and Google Scholar.

The library's webpage is a fractionated portal to hundreds of disparate resources that we try to get our users to take advantage of.⁸ Users have had to go to different search tools to access books, e-books, journal articles, patents, and so on. We present long lists for our users to navigate: lists of citation databases, individual e-journal titles, e-journal collections, primary resources, library catalogs, digital libraries, institutional repositories, and more. Google's broad and deep reach has made the “library way” an increasingly harder sell. Proxy access, OpenURL, and now unified discovery tools have made some headway in addressing these issues, but we still have a long way to go.

In essence, libraries are struggling to overcome the difficulties inherent in this world of disparate online information silos. In a print-dominated world, local silos were necessary; the collections a library had on hand largely determined the universe of items available to its users. As online content and access become the norm, physical limitations on collections begin to fall away, but information silos proliferate. Because such is the case, we still have to repeat the mantra “You need to go to the library (webpage) to search for this … or access that.”

Web services and application programming interfaces (APIs) allow data to be pulled into catalogs and resolvers from external sources. The use of these tools reduces the need to search multiple locations as well as limiting dead ends. These tools are still constrained to the exchange of small amounts of data per transaction, and there is increasing demand for “best in class” services to provide localized, up-to-date access to the entire scope of a library's holdings. There are Ex Libris customers who want to implement Serials Solutions' Summon, Serials Solutions customers who want to integrate ExLibris' bX; and Innovative Interfaces customers who want to present a different vendor's catalog discovery layer. These scenarios are difficult to impossible at this time, as libraries cannot successfully maintain multiple versions of their knowledge base or catalog, and vendors are slow to make their customers' data fully available and interoperable to each other. Labor-intensive workarounds to these challenges abound, but are ultimately unsustainable.

One bright spot in this landscape is the general recognition that more effective sharing of holdings data would be to everyone's advantage. Scholarly Information Strategies explored the concept of a “centralised” approach to knowledge base production in a report commissioned by UKSG in 2006.⁹ This model would “revolve around a single repository of content definitions and packages … that would be publicly accessible to all who desired to use it.” Although such a solution would not address local customization, it would free up significant resources currently being devoted by each vendor to create the underlying knowledge base for their own products. Personal conversations with management personnel from Serials Solutions and Ex Libris have confirmed that they would welcome the opportunity to redirect these resources into other means of improving their resolvers' functionality. It is our hope that the increasing demand for seamless exchange of library holdings will lead to a greater willingness to support regular exchange of knowledge base data in an interoperable format.¹⁰

Knowledge bases were designed to describe journal holdings. Journals are naturally aggregated at three levels: articles within issues within volumes within titles. Web access is enabling disaggregation of this content: individual articles are regularly available and discoverable outside of their traditional contexts. Author webpages, institutional repositories (e.g., Harvard's DASH), open archives (e.g. PubMed Central or arXiv), and author-choice open access (where authors can pay a fee to make their articles freely available within a for-fee journal) are making millions of individual articles available in a way that cannot be described at the issue level or above.

Knowledge bases, as they are currently constructed, are incapable of representing “holdings” at the article level. This limitation to knowledge base granularity has necessarily resulted in resolvers relinquishing linking of disaggregated content to Web search tools like Google. As noted above, this is not necessarily a drawback, as this content does not suffer from the appropriate copy problem: its universal accessibility makes it appropriate for all. However, successful integration of search-engine access to this content into resolver menus is an ongoing challenge (see chapter 3).

When referring to OpenURL's direct “competition” in library instruction sessions, one of the authors of this report often refers to the ever-growing number of static links as “fast and dumb” and OpenURL links as “slow and smart.” PubMed and Google Scholar, for example, have links that go directly to publisher content, whether it is licensed or not. These static links are preferable when the content is available, but are a dead end when the content is not. These links are necessary for independent users and users whose library does not have an effective resolver.

Since static links inherently point to a single location, OpenURL links are necessary to provide users access to non–publisher-direct content from aggregators or on the open Web. As such, libraries should seek to complement these static links with resolver functionality whenever possible. In the same vein, resolvers should be altered to include static links whenever they are the most appropriate (or only) way to access the content. This perspective, then, reflects a common theme of this report: resolvers must provide access to as broad a range of content as possible as accurately as possible, lest our users lose faith in their utility.

DOI, the Digital Object Identifier, was developed about the same time as the OpenURL. DOI linking depends on a linking service called CrossRef, which is a registration agency of the International DOI Foundation. DOIs are a way to assign persistent unique identifiers to online objects and can be one piece of metadata transported in an OpenURL. In a sense, a DOI is a hybrid between a static link and a knowledge base–driven OpenURL link. They improve on static links because they are stable persistent identifiers. They are similar to OpenURLs in that they depend on a directory of content. The DOI directory contains the DOI, citation metadata, and item URL. Publishers can update the item URL at any time when the address of the object changes. It is important to note, however, that CrossRef does not maintain library knowledge base data.¹¹

Libraries use the DOI/CrossRef system in two main ways: to retrieve DOIs that are integrated into their resolver menus, thus providing a direct link to publisher's full text, and to retrieve the bibliographic metadata for a known DOI.¹² Unfortunately, the implementation of the first case, as tested by the authors, leaves much to be desired. CrossRef links to publisher full text failed 25 percent of the time and were redundant in nearly every other case (see chapter 3). However, an extension of the second case is of crucial importance in a way not previously recognized by the authors. CrossRef has provided a means whereby DOIs on the Web can serve as source URLs, enabling OpenURL linking from the content cited in papers hosted by hundreds of publishers. We describe this functionality in detail below. It is important to emphasize that CrossRef/DOI functionality is a complement rather than an alternative to OpenURL. It cannot address the appropriate copy problem without referring to the library knowledge base by means of an OpenURL resolver.¹³

One vision of the ideal future of OpenURL link resolution involves its continued progression from foreground service to background functionality. It should, perhaps, be our goal to render as few resolver menus as possible, replacing them with one-click direct linking to the best full text version available. As discussed in chapter 3, this functionality is currently available from both major resolver vendors, although its breadth and reliability need improvement.

Another ideal complement to one-click delivery of full text would be indication of full text availability via the resolver button in the source database. There are two levels of possible functionality here. First, as the button is being rendered, the source database could query the resolver knowledge base for full text availability and insert a “get full text” version of the button whenever it finds a match, instead of the standard resolver button. Similar functionality is built in to the Ex Libris MetaLib results set; this highly desirable feature should be implemented for other sources wherever possible. The authors hope that a future iteration of link resolver software or its successor will confirm full text access before providing links to the user.

This vision and functionality have been realized in Pubget, the first implementation of an OpenURL-based “pull” technology in a search tool. Back in the early days of OpenURL, it was magical just to be able to follow the path from result or citation to full text (in any number of steps) without having to manually translate citation metadata. The next generation of OpenURL integration may obviate the need to follow a path at all, inserting full text into the search process, rather than requiring users to leave the search interface to hunt for full text (which may or may not be available to them).

Pubget

http://pubget.com

Rather than pushing the user out to the full text via a bewildering (or at least distracting) plethora of paths, Pubget pulls in PDFs and colocates them with the search result list. At first blush, Pubget's website seems to provide a magical service, free to not-for-profit organizations,¹⁴ complete with all the secrets that make magic what it is. Behind the scenes, it is a knowledge base– and resolver-driven service that reduces the number of steps from discovery to delivery to zero (when the PDF is available).

Of course, Pubget has its limitations. The universe of 25 million citations it searches consists only of PubMed, ArXiv, and JSTOR records. Like any link resolver, Pubget's accuracy is limited by the quality of the knowledge base on which it's based. Some Pubget libraries' knowledge bases were found to have accuracy levels as low as 70 percent (Madeline Abrams, personal communication, July 14^th, 2010). The company is actively developing strategies to increase library-level knowledge base accuracy by augmenting its version with library-specific, direct-from-publisher access lists. As of March 2010, Pubget chose to stop accepting new customers, instead focusing on the accuracy of PDF retrieval for its current 220 libraries. The impact of Pubget for libraries is still uncertain, but it does provide us a glimpse of a future where link resolvers function completely behind the scenes.

CrossRef has registered more than 40 million metadata records for scholarly items.¹⁶ Many of these items are cited in multiple places on the Web. Libraries can facilitate access to this content from any or bibliography or webpage that includes DOIs.

The default behavior of DOI links on the Web is to direct users to the publisher's full text. In many cases, users will not be authenticated for this access, either because they are working outside of their library's network or because their library does not license access to the publisher version of the item. Libraries have the option to configure the CrossRef server to send DOI requests through their library's link resolver rather than directly to the publisher full text.¹⁷ To accomplish this, a library registers its resolver base URL with CrossRef. Once it does so, a persistent cookie is downloaded that contains the URL for the local resolver server. This cookie enables OpenURL for DOIs within the browser, which will lead the CrossRef system to redirect DOI requests to the local resolver. The local link resolver then receives the metadata needed for link resolution, either from the source of the link or from the CrossRef DOI directory. Unfortunately, neither of the authors can vouch for the effectiveness of this service, as we have yet to implement it at either of our institutions, although we can test it through LibX-enabled right-click context menus (see the section “Leveraging COinS Coding,” below). Since this configuration replaces direct linking with resolver-based linking, it will be important for libraries to confirm that activating it will increase full text access for users. Ultimately, the extensive reach of this service into the bibliographies of millions of articles on the Web will justify its implementation.

The Web as we know it today consists of links that work and break instantaneously and that carry no indication of the relationship between one object and another. Information on the Web today is still largely text-based rather than based in machine-readable data. Simply put, humans can derive meaning from the words on a webpage, but computers cannot. The phrase Semantic Web encompasses efforts to create a framework for bringing machine-readable meaning (semantics) to the Web.

Efforts to bring bibliographic data into the Semantic Web are described succinctly and accessibly by Karen Coyle in her two LTR issues, “Understanding the Semantic Web: Bibliographic Data and Metadata” (January 2010) and “RDA Vocabularies for a Twenty-First-Century Data Environment” (February/March 2010). While it is easy to envision the application of the Resource Description and Access cataloging rules in physical libraries as they exist in the early twenty-first century, it is less clear how RDA might extend to apply to and help retrieve items not necessarily collected individually in a library, yet available and desired by our online users: articles, book chapters, dissertations, proceedings, datasets, audio, and video. Regardless of this lack of clear path, putting our bibliographic data in a machine readable framework that is more “data-like” than the current, text-heavy MARC format is a step toward making that data available for use by nonlibrary entities on the Web.²¹

Microformats constitute one effort to add structure and machine-readable context to information contained in webpages. At this time, software must be added to the Web browser so that microformats can be seen. The Operator plugin for Firefox creates a toolbar that pulls out Contact, License, Event, and other microformat data and can export or send it as a search to other websites. There are also extensions for Chrome, Safari, and Internet Explorer, though the Chrome extension detects and displays only the hCard microformat at the time of this writing.

A draft specification of the Citation microformat exists. It is similar to COinS in that a microformat can easily be embedded in any HTML page for others to use. Karen Coombs writes that COinS and the Citation microformat differ in that the latter will “break the data down into component parts to make it more flexible” rather than building on the OpenURL Context Object.²² As the Microformats.org Citation Formats page shows, there are myriad ways to display citation metadata; the discussion to create a single hCitation microformat is likely to be long and complicated.

Microformats.org Citation Formats

http://microformats.org/wiki/citation-formats