The initial (version 0.1) OpenURL syntax was developed in the late 1990s by Herbert Van de Sompel, who introduced it with Oren Beit-Arie in 2001.1 The current version, version 1.0, became a National Information Standards Organization (NISO) standard in 2004 and was reaffirmed in 2010.² OpenURL was developed to solve the “appropriate copy” problem. The appropriate copy problem refers to the need to link users to incarnations of content to which their institution subscribes.³ Electronic content may be available in more than one place (publisher website, electronic journal aggregator, etc.). End users need to be directed to the copy they have permission to access (i.e., content licensed through their institution). Before the creation of the OpenURL framework, reference linking “involved hard-coding links between one content provider and another.”⁴ Such linking was referred to as “non-context-sensitive” linking and was problematic because it did not take into account the context of the user who followed the link.⁵ As a result, users were sometimes linked to the “wrong” or “inappropriate” copy of an article, i.e., one that they did not have permission to access.

The system of Digital Object Identifiers (DOIs) was being developed around the same time as the OpenURL and led to the formation of the International DOI Foundation (IDF) in 1997.⁶ DOIs are persistent, unique links assigned to digital content such as electronic journal articles. Each DOI is “paired with the object's electronic address, or URL, in an updateable central directory, and is published in place of the URL in order to avoid broken links while allowing the content to move as needed.”⁷ While DOIs offer persistent links that resolve even when content moves (because of, for example, a publisher or platform change), the DOI system has no mechanism to select the “appropriate copy” for particular users, and is therefore subject to the same appropriate copy problem that the OpenURL framework addressed. DOIs typically link to the publisher's site, regardless of whether the user has permission to access the content on that site.⁸ If a user has access to content through, for example, an aggregator database but not at the publisher's website, the DOI system alone has no way of knowing this. The OpenURL framework, on the other hand, is a dynamic linking model that can perform context-sensitive linking, “whereby links are flexible and able to take into account the user's institutional affiliations and the licenses of that institution.”⁹ OpenURL created a linking mechanism that takes into account what the particular user is allowed to access. By doing this, OpenURL solved the appropriate copy problem.

Realizing the limitation of DOIs with regard to the appropriate copy problem, DOI developers adjusted the system to work with OpenURL.¹⁰ Today the DOI system has the ability to identify a user's institutional affiliation and, using the OpenURL framework, send the request for electronic content through the institution's local link resolver instead of to the publisher's site. This solution, offered only to library affiliate members of CrossRef, the official DOI registration agency, provides “appropriate copy” resolution of DOI links.¹¹ While DOI was originally part of the appropriate copy problem, it now works together with OpenURL to connect users to licensed electronic content they are authorized to use.

The OpenURL standard specifies a particular syntax for the transport of content-specific metadata, such as International Standard Serials Number (ISSN), volume, issue, start page, and article title, as well as the user's institutional affiliation (to know what the user has permission to access). When a user clicks on a citation from, for example, an abstracting and indexing database, the OpenURL builds a URL string that uses the bibliographic metadata from the citation to “check all of the library's holdings and retrieve the full text if a match is found.”¹² Because this link is where the OpenURL linking process begins (the source), it is referred to as the “source link” or “outbound link.” The structure of an OpenURL source or outbound link is illustrated in the following URL:

http://anylibrary.anyresolver.com/?genre=article&sid=[source ID]&issn=[ISSN]&title=[journal name]&atitle=[article title]&volumne=[volume]&issue=[issue]&space=[start page]&date=[yyyy]¹³

The brackets indicate place holders for specific citation data. For simplicity's sake, this example utilizes version 0.1 of the OpenURL syntax; version 1.0 is similar but more complex.

Two key components of successful OpenURL linking are the link resolver and the knowledge base. The OpenURL standard defines the specifications and syntax of the OpenURL (for example, “atitle” means “article title”), but it is the link resolver, together with the knowledge base, that processes the information and ultimately provides users with links to appropriate copies.

A link resolver is “a software tool that deconstructs an OpenURL, separates out the elements that describe the required article, and uses these to create a predictable link to the appropriate service(s) identified by the user's library.”¹⁴ The “link to the appropriate service” is the link that takes users to the licensed full-text content, wherever it may reside (publisher's website, aggregator, etc.). Links to target content (as opposed to links from a source citation) are referred to as “target links” or “inbound links.”

A knowledge base is “an extensive database … that contains information about electronic resources, such as title lists, coverage dates, inbound linking syntax, etc.”¹⁵ “Inbound linking syntax” refers to the information on how to construct the target or inbound link, the link to the content at the target website (e.g., publisher's website). Individual libraries customize the knowledge base so that it reflects their particular holdings. Libraries do this by activating their subscribed or licensed content within the knowledge base. Activated titles are those the library users are entitled to access; they are the “appropriate copies” for that particular library's users. Libraries must be careful to activate only the content they have licensed.¹⁶ Although the link resolver does the linking, it relies on the knowledge base for information regarding which copies are “appropriate” (those activated) and for the metadata necessary to create a successful link to content (target link). Figure 1 outlines the basics of OpenURL linking.

When a user clicks on a citation (the source), a source OpenURL is generated (see above). The link resolver then deconstructs the OpenURL, parsing out the metadata (ISSN, atitle, etc.) and matches it to the information in the knowledge base (to determine whether the library has access to the content, i.e., whether there is an “appropriate copy”). If a match is found, the link resolver generates a results page with target links to the appropriate copy or copies. The link resolver creates the target links using the link-to syntax (the formula used to construct target links) and bibliographic metadata that is stored in the knowledge base.

To summarize, OpenURL is a framework that specifies syntax for context-sensitive reference linking. The link resolver is the software that does all the linking. Using the specifications and syntax of the OpenURL standard, the link resolver pulls apart the OpenURL source link (created from a citation), searches for a match in the knowledge base (which is customized by individual libraries so that it reflects the particular library's exact holdings), and, if a match is found, creates a target link to the full text using metadata in the knowledge base.

With OpenURL, the actual link to electronic content is no longer hard-coded or static, but rather flexible and dynamic. It is specific to the particular user's permissions and thus the target URL will be different for different users. OpenURL linking solved the appropriate copy problem and was deemed a great breakthrough for library reference linking. Since its ratification, the OpenURL framework has been widely adopted within the scholarly information supply chain.¹⁷

Despite the advent and wide adoption of OpenURL and DOIs, linking problems still occur. In their study on link resolver accuracy rates, Trainor and Price found that links failed nearly a third of the time (29 percent).¹⁸ An earlier study by Wakimoto, Walker, and Dabbour found that 20 percent of the full-text link options generated by their institution's OpenURL link resolver were erroneous, “either because they incorrectly showed availability (false positives) or incorrectly did not show availability (false negatives).”¹⁹ Both false positives and false negatives are forms of link failures. The broken link is the result of a false positive. While broken links are frustrating, false negatives are more elusive and arguably more troublesome. With no link to content appearing at all, false negatives represent a kind of unknown failed access that “can be more damaging to the user.”²⁰ False negatives also represent paid content that is not being discovered and thus not being used. This both reduces the library's return on investment and leaves users dissatisfied.²¹

While the Wakimoto, Walker, and Dabbour study seems to have resulted in a lower rate of link failures than the Trainer and Price study (20 percent versus 29 percent), Trainor and Price make a compelling argument for the reassignment of the Wakimoto, Walker, and Dabbour category “Correct—required search or browse for FT [full text]” from the “correct group” to the “error group,” stating that “When the target full text item or abstract with full text links is not presented on the target page, most users and even many librarians perceive the resolver as having failed.”²² This reassignment raised the total link resolver error rate for the Wakimoto, Walker, and Dabbour dataset to 35 percent.²³

Link failures can occur in various stages along the OpenURL linking chain. If the metadata from the source citation is incorrect or incomplete, the link resolver may not be able to match it to the information in the knowledge base. If the metadata in the knowledge base is incorrect or incomplete, a match will similarly fail. Moving through the OpenURL linking chain, errors also can occur at the target website. Trainor and Price refer to these three main causes of link failures as source URL errors, knowledge base inaccuracies, and target URL translation errors.²⁴

The creation of KBART in January 2008 was a direct result of the findings of the UKSG report Link Resolvers and the Supply Chain.⁴⁸ As mentioned earlier, the report underscored the significance of the knowledge base in OpenURL linking and noted a need for education about how data provided by content providers to knowledge bases directly affects the efficiency of OpenURL linking. The report found numerous linkage errors because of inadequate data sent from content providers and noted that no standard guidelines existed for data transfer from content providers to knowledge base vendors. KBART was formed to remedy this situation.

KBART was specifically charged with improving “the supply of data to link resolvers and knowledge bases, in order to improve the efficiency and effectiveness of OpenURL linking.”⁴⁹ Since its creation, KBART has worked to alleviate “problems in the information supply chain that relate to the data supplied to knowledge bases.”⁵⁰ This is a very specific goal that deals directly with the OpenURL linkage problems described earlier. By recommending best practices for the accurate and timely exchange of holdings metadata from content providers to knowledge bases, KBART strives to improve OpenURL linking and decrease the incidences of failed access.

The KBART working group completed phase 1 of its work in January 2010 with the publication of KBART: Knowledge Bases and Related Tools: A Recommended Practice of the National Information Standards Organization (NISO) and UKSG.⁵¹ The publication contains specific guidelines and instructions for enabling the accurate and timely exchange of holdings metadata from content providers to knowledge base developers. Designed to be intuitive and easy to implement, KBART hopes that “by making some small adjustments to the format of their title lists, content providers can greatly increase the accessibility of their products,” libraries can enjoy a higher return on their investment, and users will experience fewer link failures.⁵²

The KBART report encourages content providers to include sixteen specific fields as columns in a tab-separated metadata file and, for consistency, to use the field labels specified in the report (see table 1). In deciding on these sixteen elements, the goal was to “collect only the information that is most useful, rather than a large number of fields that become too overwhelming for content providers to support.”⁵³ The recommendations address common metadata problems such as the reuse of ISSNs; title inconsistencies (misspellings, the incorrect use of former or subsequent titles); inaccurate or outdated coverage dates; inconsistent date and enumeration formats; inaccurate, inconsistent or missing coverage descriptions (e.g., abstracts, selected full text, exclusion of graphics); and embargo period ambiguities. The report also includes recommendations for metadata file naming as well as the method and frequency of data transfer.

KBART offers content providers a simple metadata exchange format that is easy to follow, easy to implement, and easy for knowledge base developers to process. While many content providers already successfully exchange metadata, others are unsure how best to proceed. KBART offers “entry-level guidelines and instructions” for the timely and accurate exchange of essential holdings metadata.⁵⁴ The benefits of adopting the KBART best practices span the entire electronic serials supply chain: content providers enjoy a reduction in cost of their customer service, an improved reputation, and increased traffic to their content; knowledge base developers spend less time retrieving missing metadata and reformatting data into a single normalized format; and libraries benefit by “maximizing the usage (and therefore the return on investment) of the content they license, and [improving] the experience and success rate of their users as they navigate the research network.”⁵⁵

While KBART's phase 1 work focused on metadata exchanges for journals, phase 2 focuses on more advanced, complex issues such as metadata for consortia, open access content, e-books, and conference proceedings.⁵⁶ Phase 2 also includes work on an information portal that will provide educational resources such as background information on the OpenURL and the serials supply chain, “how to” guides, and selected links to pertinent literature. KBART continues a robust outreach effort to educate and inform the community, and to increase the number of publishers that adopt the practices recommended in the phase 1 report. At the time of this writing, forty-seven publishers and organizations have endorsed KBART.⁵⁷

The IOTA working group was formed by NISO in January 2010 “to investigate the feasibility of creating industry-wide, transparent and scalable metrics for evaluating and comparing the quality of OpenURL implementations across content providers.”⁵⁸ Like KBART, IOTA is concerned with link failures resulting from problems with the metadata that fuel the OpenURL. IOTA's goal is to measure source OpenURL quality across content providers to pinpoint problematic areas that can then be the focus of improvement efforts. By using metrics to automatically and systematically evaluate OpenURLs, IOTA strives to supply objective, empirical data on exactly where metadata problems exist so that content providers can efficiently and effectively target efforts to improve OpenURL linking.

IOTA has its origin in the study by Chandler referenced earlier.⁵⁹ As mentioned above, Chandler manually reviewed a sample set of OpenURLs and found numerous typical metadata problems. These kinds of problems cause links to fail. Fixing these problems would increase successful OpenURL linkage, instantly increasing users’ access to licensed content (and decreasing their frustration with failed access). By systematically and objectively identifying precise areas of metadata deficiencies, IOTA hopes to “inform vendors about where to make improvements to their OpenURL strings so that the maximum number of OpenURL requests resolve to a correct record.”⁶⁰

As of July 2011, the IOTA OpenURL reporting system contained more than 15 million OpenURLs from fifteen institutions and content providers.⁶¹ The reporting system analyzes the element frequency and patterns contained within OpenURL strings. Users can run reports that show, among other things, which elements (e.g., article title, ISSN, etc.) are present in the OpenURLs. Such a report could, for example, reveal that the OpenURLs from a particular content provider, “provider X” do not contain a particular OpenURL element such as “spage” (the start page number for the item). This can be compared to other providers. If a high percentage of other providers include the element, this could be a cause of unsuccessful OpenURL links from provider X. Another kind of report can show element patterns, such as the format used for the date of an item. Date formats vary from four digit year formats (2011) to formats that indicate the month with or without the day and with or without hyphens (e.g., 2011-06, 2011-06-20, 20110620). The IOTA reporting system can analyze the OpenURLs and show, for example, that provider X uses the date format YYYY-MM-DD (2011-06-20), while most providers use the year only (2011). This may or may not be the cause of Open URL link failures, but equipped with this knowledge, provider X could focus its attention on this area, make any necessary changes, and improve OpenURL linkage (and thus traffic) to its content in a cost-effective way. In short, such reports allow vendors to see weaknesses in their source OpenURL strings, make targeted improvements, and thus increase access to their content (and decrease broken links).

KBART and IOTA are both working to decrease OpenURL link failures that are caused by metadata deficiencies. IOTA works to decrease source URL errors by analyzing the data that enters the OpenURL chain from the source citation, while KBART focuses on decreasing link failures because of knowledge base inaccuracies by improving the flow and accuracy of the metadata that content providers send to knowledge bases.

PIE-J differs from KBART and IOTA because it is not focused on link resolver errors. Formed by NISO in 2010, PIE-J addresses access barriers that arise from the manner in which electronic journals are presented on provider websites. PIE-J's official charge is

to develop a Recommended Practice that will provide guidance on the presentation and identification of e-journals, particularly in the areas of title presentation and bibliographic history, accurate use of the ISSN, and citation practice, that will assist publishers, platform providers, abstracting and indexing services, knowledgebase providers, aggregators, and other concerned parties in facilitating online discovery, identification, and access for the publications.⁶²

Expected to be published in the first half of 2012, the recommended practice will specifically address the issues of varying titles for different formats, accurate title history information, citation practices, and accurate use of ISSNs. The ultimate goal is to ensure that electronic content can be reliably discovered, cited, and accessed over time.

As described earlier, provider websites sometimes lead users down a confusing path by placing content that was published under former journal titles together with content published under the current title. This practice impedes access when users search for content using historically correct citations from abstracting and indexing services, bibliographies, published works, and other research tools. These citations use the title a journal carried at the time the particular article was published. Users need to be able to find the article with the citation in hand. For this to happen, electronic journal websites must accurately and uniformly present all the titles under which content was published. In short, content providers should present former journal titles “with enough prominence on the website to be easily visible and well enough indexed to be accessible via a search engine.”⁶³

Insufficient identification of former titles also can affect current citation practices, another issue PIE-J is addressing. Many journal websites today offer online citation tools that purport to generate accurate article citations. When older content is placed on websites under the newer title, the citation tool often generates a citation using the journal's current title. This is not correct and, left unattended, will impede future access.

Lacking any standards or guidelines for the presentation and identification of electronic journals on websites, the information regarding title history, title variation, and ISSN history is not always unambiguously supplied. PIE-J's goal is to review the problem and provide guidelines in the form of a set of NISO-recommended practices on how providers can best mount title history, including ISSN history, on their websites to facilitate identification, access, and reliable citation practices over time. While PIE-J does not address OpenURL linkage issues, their recommendations on the accurate use of ISSNs would, if widely adopted, improve linking.