The OpenURL Emerges

One of the key problems with static, direct linking is this sort of linking fails to take the user's context into consideration at the moment of clicking, causing the aforementioned appropriate copy issue. Thus, context-sensitive linking, using dynamic-linking technology, emerged as a solution.

Context-sensitive linking is just as it implies: it takes the user's context, usually meaning his or her affiliations but possibly also the user's intent for desired information objects, into account; therefore, ideally, context-sensitive linking only offers links to content the user should be able to access (i.e., appropriate copy). Furthermore, in addition to addressing the appropriate copy issue, context-sensitive linking could conceivably offer links that anticipate a user's intent for desired content.

The OpenURL is just one example of context-sensitive dynamic linking in action, but it is also one of the most widely used. One of the most attractive features of the OpenURL is it puts linking control back into the local library's staff members’ hands. In an e-mail correspondence with the author on March 1, 2004, Chemical Abstract Service (CAS) manager (ChemPort Marketing) Harry Boyle astutely noted that, “The solution to the appropriate copy problem (a big part of it anyway) is to make it easy for the user to link to his own library. It is the user's library that knows which copy (meaning access path) is the correct one for him.”

Indeed, the local library or information center is best situated to point users along the correct access path to those copies to which users have rightful access. The OpenURL enables this localized control.

Local library control is only half of the equation, however. Most institutions subscribe to a wide variety of electronic resources, and the ability to control what links do and do not appear in each resource is key to a local library's success in providing accurate links. Yet, without some centralized mechanism, the local library is faced with entering and maintaining links in each resource. When the librarian accurately configures a service such as SilverLinker to link out to appropriate copies for his or her constituency, this is only one service that is so configured. The librarian must then go to EBSCO, Cambridge Scientific Abstracts, and so on, and perform the same task in each of those services’ linking tools. This is no small burden, as journals continually fall in and out of various publishers and aggregators; therefore, the OpenURL, through its implementation via link-resolver products, allows the librarian to enter accurate electronic holdings information in one place—in its institution-specific instance of a link-resolver's knowledgebase, thus enabling more accurate, context-sensitive external linking amongst its e-resources. Although this centralized data input is a key feature of link resolvers, some libraries have not implemented link resolvers, so vendor-specific linking options remain important.

In addition to providing the crucial central mechanism that allowed libraries to realistically manage their linking solutions, the OpenURL has become increasingly robust, particularly in its current iteration as American National Standards Institute (ANSI)/National Information Stan-dards Organization (NISO) standard Z39.88-2004.¹

OpenURL stands for “Open Uniform Resource Locator,” and it was initially in use as OpenURL v. 0.1, before standardization by ANSI/NISO as OpenURL v. 1.0. The OpenURL allows for linking beyond traditional proprietary full text, to the open access that defines the World Wide Web. The “Z39.88-2004 OpenURL FAQ” describes the value of the OpenURL standard: “The OpenURL Standard is the foundation for Web browsing … customized to the user. Clicking on an OpenURL link sends bibliographic information in it to a networked service. Instead of getting back anything and everything, the user gets immediate access to the most appropriate copy of that resource. ‘Appropriateness’ reflects the user's context such as location, cost of the item, and contractual or license agreements in place with information suppliers.”²

In essence, the OpenURL standard allows for the creation of a link path that takes users where they need to go in order to access their appropriate copies. In its implementation via link resolvers, it has the potential to create a seamless research environment.

The OpenURL Framework for Context-Sensitive Services

www.niso.org/standards/standarda_detail.cfm?std_id=783

NISO's “Z39.88-2004 OpenURL FAQ: Technical Overview”

www.niso.org/standards/resources/OpenURL_FAQ.html

Technology behind the OpenURL

Before moving too quickly into the technology of the OpenURL, discussing the vocabulary associated with it is useful, including how it inserts a user's context into the linking equation. Unlike a traditional URL, the OpenURL does not point to a static address indicating the location of the desired information object. Instead, the OpenURL contains data identifying the desired object, much like a MARC record identifies the item itself, not a specific copy of the item. Yet, the OpenURL goes further than just identifying the desired object; it also inserts the user's context into the linking framework. The information about the object is only part of the power of the OpenURL.

For journal articles, the metadata included in the OpenURL can take the form of an ISSN, publication date, or other journal and article specific information. In the place of traditional metadata such as the ISSN, the OpenURL could include a unique identifier, such as a Digital Object Identifier (DOI). Again, because an OpenURL does not identify one specific copy of the full text, multiple copies of an article can be identified using one OpenURL. Additionally, because OpenURL v. 1.0 is more flexible than its predecessor, v. 0.1, OpenURLs can contain metadata pointing to more than just scholarly articles, including patents, mathematical and chemical formulas, or even non-scholarly items such as real-estate listings or news stories.³

Identifiers are unique-naming schemas assigned to a particular information object, and there are many in use, including the Serial Item and Contribution Identifier (SICI), the PubMedID (PMID), and the Digital Object Identifier (DOI), which is one of the most popular and the one that will be the primary focus in this report. As mentioned previously, not all information objects have unique identifiers, so the metadata embedded in an OpenURL varies.

It is important to remember the OpenURL is only a “protocol that standardizes the extraction and transmission of those metadata elements” included in an OpenURL.⁴ In other words, the OpenURL does not itself standardize metadata, but rather, the way that metadata is extracted and transported. In an article containing interviews with members of the NISO Committee responsible for the OpenURL standard, NISO Committee AX, Arthur Hendricks noted, “Most stated that OpenURL is not a metadata format in itself, but a means of transporting metadata.”⁵ This distinction is important because it points to how the OpenURL is implemented, through link resolvers, also called link servers.” Link resolvers take the standardized transport of the metadata in the OpenURL and interpret it, applying “as much logic as they can” and then offering “the user a menu showing a range of possibilities” and services (see figure 2 below).⁶

The OpenURL v. 0.1 contains two basic parts. The first part is what's referred to as the “base URL,” and the rest of the OpenURL is “called a ‘descriptor,’ and consists of a defined set of variables tacked on to the URL in HTTP Get method fashion.”⁷ The base URL usually contains the “hostname of a library-controlled server (or resolver) that processes the data in the rest of the OpenURL.”⁸

Let's take a look at a sample OpenURL, v. 0.1:

• ▪ Base URL: http://resolver.university.edu/?9
• ▪ Descriptor, or what follows the base URL: atitle=Hegel's+dialectic+and+the+recognition+of+feminine+difference&auinit=A&aulast=Stone&date=2003&epage=139&issn=0031-8256&issue=5&sid=ISI:WoK&spage=132&stitle=PHILOS+TODAY&title=PHILOSOPHY+TODAY&volume=4710

In the OpenURL v. 0.1 framework, links travel from sources to targets. Sources are simply where the user begins his or her search and can include abstracting and indexing services, OPACs, staff modules of integrated library systems, publisher's Web sites, aggregators, or freely available Web search engines such as Google Scholar. Targets are where the user ends his or her search. Targets can include OPACs, publisher's Web sites, aggregators, and much more. The SFX Web site explains, “for an information service to be OpenURL-aware, the service must be able to distinguish between users who have access to a link server, such as SFX, and those who don't.” For example, the DOI directory of the CrossRef system is OpenURL-enabled, meaning “it can recognize a user with access to a local resolver.”¹¹

“Shoehorning the Sacred into the Profane,”by Ross Singer (presented at the NISO September 2005 Workshop: OpenURL and Metasearch: New Standards, Current Innovations, and Future Directions)

www.niso.org/news/events_workshops/OpenURL-05-Agen-FINAL.html

The SFX Web site then goes on to give a brief list of methods for making this distinction, which include: information stored in a cookie, information contained in a digital certificate, IP address, or Shibboleth.¹² For example, the DOI directory of the CrossRef system uses a Cookie Pusher script.¹³ A more complete description of the Ex Libris Cookie Pusher is available at www.exlibrisgroup.com/sfx_cookiepusher.htm.

As Dahl indicates, the link resolver is usually under the control of the local library or consortium. Furthermore, the link resolver basically contains two components: the linking engine and the knowledgebase. In a conversation with Eric Hellman, director of OCLC Openly Informatics, he explained that the linking engine is essentially the component that produces the links—for example, it contains all the link-to syntaxes for various targets. Additionally, the linking engine performs error checking and preprocessing to look up titles or ISSNs should the source not send this metadata in the OpenURL.¹⁴ If it is a commercial link-resolver product, the link resolver can either physically reside as a link server at the institution or be remotely hosted by the vendor. When evaluating a vendor's link-resolver product for purchase, the server location is a key feature to consider; if the server resides locally at the library, then staff time and expertise must be part of the decision about which service to purchase.

One of the allures of the link-resolver vendor is its ability to offer a global knowledgebase of all possible full-text information objects. For example, a global knowledgebase theoretically should contain all possible iterations for a given journal, particularly all proprietary copies. For example, the Journal of Black Studies is available from the following vendors for the following dates:

• ▪ 9/1/1970 to 11/1/2001 in JSTOR;
• ▪ 1/1/1997 to 11/1/1998 in the following Thomson Gale products: Academic ASAP, Expanded Academic ASAP, General Reference Center—International, General Reference Center Gold, InfoTrac Custom, InfoTrac OneFile, Student Resource Center College (w/ Academic ASAP), Student Resource Center College (w/ Expanded Academic ASAP);
• ▪ 1998 in OCLC First Search's Periodical Abstracts;
• ▪ 1999 to 2005 in OCLC First Search's Electronic Collections Online;
• ▪ 1/1/1999 to present in EBSCOhost EJS, Highwire Press, Sage Publications and SwetsWise; and
• ▪ 2001 to present in Chadwyck-Healey's International Index to Black Periodicals Full Text.

For the average local library, the task of tracking a given journal's many iterations (including coverage dates) is overwhelming for available staff; therefore, the link resolver's global knowledgebase of all these possibilities is a major selling point.

Ex Libris's “Open URL Overview”

www.exlibrisgroup.com/sfx_openurl.htm

Ex Libris Cookie Pusher

www.exlibrisgroup.com/sfx_cookiepusher.htm

Openly Informatics Inc.

www.openly.com

The local library indicates which copies it has purchased, creating a local knowledgebase (for example, its institution-specific instance of the global knowledgebase) that mirrors its own subscriptions. Although the local library may have purchased access to the Journal of Black Studies from JSTOR and EBSCOhost EJS, it may not have purchased it from SwetsWise; therefore, the local knowledgebase needs to be configured so the link resolver offers links only to JSTOR and EBSCOhost EJS and not to SwetsWise. This configuration is usually as simple as checking off options in a Web-based administrative module, but depending on the number of electronic-journal subscriptions a library has, this step can also be the most time consuming. Having implemented link resolvers at two large academic institutions with more than thirty thousand electronic journal subscriptions with varying subscription dates, I found that the knowledgebase configuration can be quite tedious. Most commercially available products offer batch uploading of some sort, but the data must be in some importable format for population of the knowledgebase.

The intermediary menu is a screen that appears to the user between the source and the target. The average menu can include the following elements: the original citation and some mechanism that allows the user to change the bibliographic information; links to appropriate copies of full text; links to the local catalog; links to ILL; and links to help of some sort, such as Frequently Asked Questions (FAQs) and/or virtual reference services (Ask-A-Librarian or e-mail addresses). Libraries are incorporating all sorts of other extended services on the intermediary menu, and the creative ways in which they are doing this are explored in chapter VI, “Innovative Uses of the OpenURL.”

OpenURL and CrossRef/DOI

The OpenURL in its first version, v. 0.1, contains the two elements needed for a context-sensitive linking framework: the localized control via the link resolver (base URL) and the standardized transport of the metadata describing the information object (unique identifiers, ISSN, etc.). If unique identifiers (such as the DOI) are used, however, how does the link resolver interpret them? Link resolvers need the assistance of some sort of comprehensive reference database in order to deliver the corresponding URLs that are associated with DOIs. CrossRef performs this function.

DOIs are administered by the International DOI Foundation, “an open membership consortium including both commercial and non-commercial partners,” which “has recently been accepted for standardisation within ISO.”¹⁶ DOIs are assigned by DOI Registration Agencies; a full and updated list is available on the DOI Web site (www.doi.org). In essence, “The DOI was developed as a cross-industry, cross-sector, not-for-profit effort managed by an open membership collaborative development body, the International DOI Foundation (IDF) founded in 1998.”¹⁶ The DOI is broken down into two distinct parts, a prefix and a suffix. The prefix is assigned to a specific publisher, and every information object from that publisher has the same DOI prefix. The suffix is assigned by the publisher to identify each individual article. Many publishers number their articles consecutively or use some other simple numbering scheme.

Following are sample DOIs, the first uses a simple numbering scheme, and the second uses a metadata-driven numbering scheme:

• ▪ DOI: 10.1002/he.185—For this DOI, 1102 represents Wiley as the publisher. he is the journal New Directions for Higher Education. The final three digits, 185, represent the article, “Community Service as Learning,” by Jodi L. Anderson. The full citation for this article is: Anderson, Jody L. “Community Service as Learning.” New Directions for Higher Education 2005, no. 131 (Autumn 2005): 37–48.
• ▪ DOI: 10.1089/as.2005.5.331—For this DOI, 1089 represents Mary Ann Leibert as the publisher. ast is the abbreviation for the journal Astrobiology. 2005.5.331 represents the article. Mary Ann Leibert chooses to use article level data in the DOI. 2005 is the year, 5 is the volume number, and 331 is the starting page number. The full citation for the article is: Sleep, Norman H. “Cutting Anthropic Knots and the Rise of O2.” Astrobiology 5, no. 3 (June 2005): 331–332.

In a short February 2004 Computers in Libraries article, Shin Kennedy outlines the pros and the cons of the DOI. In the pros column: “DOI links are persistent. A DOI functions as a standard machine-readable number, allowing for cross-system communication. Once registered, DOIs can be used freely by anyone and are easily modified without requiring re-registration. DOIs can incorporate existing ID information, such as ISBNs, SKUs, etc.”¹⁷ For the purpose of this report, one of the main achievements of the DOI is that it works in conjunction with the OpenURL.

On the other side of the coin, however, Kennedy notes the DOI “spec is oriented toward publishers rather than the library community. Furthermore, DOIs are not yet common in Web URLs; the standard is obscure to most outside of the information professions.”¹⁸ Norman Paskin, the International DOI Foundation's director, echoes Kennedy's last sentiment, noting in 2003, “A number of issues remain to be solved. In the main these are no longer technical in nature, but more concerned with perception and outreach to other communities.”¹⁹

Indeed, the DOI has a variety of attractive features, but still, some work has to be done in order for it to penetrate the non-library world.

When discussing DOIs and context-sensitive linking, CrossRef (www.crossref.org) inevitably appears in the conversation. CrossRef is a service of the Publishers International Linking Association (PILA). CrossRef was the first official DOI Registration Agency authorized to register DOIs and maintain a DOI database. As of November 1, 2005, CrossRef had registered 17,861,858 DOIs for articles and other content items; it covers 13,089 journals. CrossRef has more than 1,506 participating publishers and societies and 621 participating libraries.²⁰ Publishers assign DOIs to each information object they publish and deposit those DOIs and the corresponding URLs in the CrossRef database. Once a DOI has been assigned to an article or information object, any aggregator can use that DOI; therefore, if two aggregators want to provide OpenURL links to an article in the Review of Economic Studies, they would each use a single DOI created by the publisher of the journal.

“The Digital Object Identifier System”

www.doi.org

“The Digital Object Identifier System: Introductory Overview”

www.doi.org/overview/sys_overview_021601.html

“DOI: A 2003 Progress Report,” by Norman Paskin

www.dlib.org/dlib/june03/paskin/06paskin.html

Usually, libraries need to be CrossRef affiliates to be able to use CrossRef's DOI database in conjunction with their link resolver. Although with some link resolvers, such as SFX (Ex Libris) and Article Linker (Serials Solutions), libraries do not need to sign up for individual affiliate membership. There is no charge for being an affiliate member, unless the library submits a high number of queries.²¹ CrossRef also offers its free DOI resolver (www.crossref.org/05researchers/58doi_resolver.html), with which anyone can conduct a search to find to what information object a DOI is referring. Alternately, anyone can use the free DOI look-up (www.crossref.org/guestquery), which allows users to enter bibliographic data to discover if a DOI has been assigned to it by CrossRef.

CrossRef itself holds no full-text content; the CrossRef database only holds the data supplied by participating members. The database functions as a digital switchboard, matching DOIs with data and then redirecting requests to the URL provided by the publisher. CrossRef's ability to link the user to the full text is limited, in that it can only direct the user to the URLs supplied by its members. CrossRef alone cannot identify those resources to which the library subscribes.

Ed Pentz, executive director of PILA and CrossRef, however, noted in 2003, “CrossRef worked with link-resolver vendors and libraries to make the DOI system OpenURL-enabled, so DOIs are routed to link resolvers where appropriate.”²² Further, Ex Libris's, Jenny Walker, VP of marketing & business development (Information Services division), noted in 2003, the “OpenURL/link resolver and CrossRef/DOI work together in two key ways. First, OpenURL, via a link resolver such as SFX, addresses the appropriate copy issue inherent in CrossRef. Second, if a publisher does not have a propriety ‘link-to’ syntax that facilitates the linking from a link resolver to an article, article-level linking may still be possible via an article's DOI.”²³ A simplified graphic representation of this cooperation in action is produced in figure. 3 (see page 19).

Like other linking efforts, CrossRef initially focused on scholarly journal articles, but it is now including all sorts of other content, including conference proceedings and reference books. CrossRef members can choose to create outbound links from the reference lists of their content; ScienceDirect offers this functionality, but it is not optional for libraries, meaning the CrossRef links cannot be deactivated in the references.

Additionally, in 2004, CrossRef unveiled a forward-linking option, which allows members “to display cited-by links in the primary content that they publish.”²⁴ This optional tool facilitates an “articles citing this article” feature, and publishers such as the Institute of Physics and the Public Library of Science are participating. For examples of forward linking, visit www.crossref.org/02publishers/forward_linking_howto.html.

CrossRef

www.crossref.org

“CrossRef Indicators”

www.crossref.org/01company/crossref_indicators.html

Cross Ref's “Info for Libraries”

www.crossref.org/03libraries/index.html

CrossRef's “DOI Resolver”

www.crossref.org/05researchers/58doi_resolver.html

CrossRef's “Free DOI Lookup”

www.crossref.org/guestquery

CrossRef's “Forward Linking”

www.crossref.org/02publishers/forward_linking_howto.html

CrossRef's “Multiple Resolution”

www.crossref.org/mr/mr_main.html

“CrossRef Deploys Free OpenURL Resolver” Press Release

www.crossref.org/01company/pr/press081505.htm

CrossRef also has other linking initiatives in pilot phases or in general release, such as the multiple resolution pilot (www.crossref.org/mr/mr-main.html) and its freely available OpenURL resolver (www.crossref.org/01company/pr/press081505.htm) released in August 2005. More description of the CrossRef OpenURL resolver appears in chapter IV, “Link-Resolver Products.”

Finally, many vendors, such as EBSCO and Ovid, host the CrossRef database locally, which allows them to offer a variety of linking options, including internally constructed dynamic linking at EBSCO, or SmartLinks. Vendor-supplied linking solutions are discussed in more detail in chapter V, “Linking without a Stand-Alone Link Resolver.”

NISO Standardization: OpenURL v. 1.0

Thus far, description has mainly focused on OpenURL v. 0.1, which was the de facto industry standard before NISO assigned a committee to more formally evaluate and standardize the technology. The resulting body was the NISO Committee AX, chaired by Eric F. Van de Velde, Ph.D., the director of Library Information Technology at the California Institute of Technology. 25 OpenURL v. 0.1, however, had its limitations, as described by Grogg and Ferguson:

• The OpenURL v. 0.1 syntax pre-defines both the metadata elements used to describe a resource and the protocol for file transmission. The prescribed metadata elements can include the author, titles, ISSN, year of publication, volume and issue information, page numbers, and the DOI, as well as other item specific information. However, if an information resource cannot be described using the predefined elements, then the v. 0.1 syntax may not be able to accommodate it. In terms of data transmission, OpenURL v. 0.1 is tied to the HTTP protocol for transmission of the metadata elements to the link resolver and does not accommodate any other file transfer methods. Another limitation in the v. 0.1 syntax is the context of the OpenURL link, which is defined strictly by the address of the resolver, the data elements provided about the item, and the source of the link (the database or resource in which the OpenURL link was found). Most importantly, the syntax does not provide a way to further define the metadata elements, file transmission method, or the context of the object.²⁶

Thus, the OpenURL v. 1.0 was developed to address these limitations, in essence to generalize the OpenURL both within the scholarly domain and beyond scholarly information communities.

Ultimately, the development of 1.0 has created more opportunities for more types of links and more formats to be included in open-linking environments. Let's take a look at the descriptor portion of a sample OpenURL v. 1.0 (Z39.88):

ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.atitle=Hegel's+dialectic+and+the+recognition+of+feminine+difference&rft.auinit=A&rft.aulast=Stone&rft.date=2003&rft.epage=139&rft.issn=0031-8256&rft.issue=5&rfr_id=info:sid/ISI:WoK&rft.spage=132&rft.stitle=PHILOS+TODAY&rft.jtitle=PHILOSOPHY+TODAY&rft.volume=4727

Notice how the fields differ from the sample OpenURL v. 0.1 given earlier.

According to Ex Libris's chief strategic officer Oren Beit-Arie (who, along with Herbert Van de Sompel and Patrick Hochstenbach, is one of the OpenURL's original developers), the first-generation OpenURL v. 0.1 was designed to address a fairly limited scope of genres (such as scholarly articles, etc.); in fact, v. 0.1 only addressed those genres its developers considered at the time.

NISO Committee AX, “Development of an OpenURL Standard”

http://library.caltech.edu/openurl

What its developers have discovered, however, is that even within the domain of the scholarly communication environment, there are many more opportunities for linking that go far beyond what was available through the mechanisms in v. 0.1.

Also within the scholarly domain, the design of v. 0.1 was oriented toward services presented to end users via a format that enabled link servers to present a menu of services to end users. With the development of v. 1.0, the NISO Committee AX took it a bit further, and through the introduction of proper mechanisms, the OpenURL can now be used to enable server-to-server communication—so v. 1.0 is no longer just server to browser, as v. 0.1 was.²⁸

Beyond the scholarly communication domain are the extensibility mechanisms that the NISO Committee AX built into 1.0, and these indeed enable more formats, more descriptors, and more ways to represent and encode the data—for example, XML formats and more transportation mechanisms. This greater extensibility is governed through a registry, which includes community profiles; with such a framework in place, it is then possible to go beyond the scholarly information community. In a July/August 2001 D-Lib Magazine article, Van de Sompel and Beit-Arie address the motivations for such generalizations that allow open linking beyond the traditional scholarly information community.²⁹

OpenURL v. 0.1 did provide some context-sensitive linking, in that the links behaved differently for different users if indeed those users come from different organizations. In a telephone conversation, EBSCO Information Services e-resources chief strategist Oliver Pesch explained that, in terms of context-sensitive linking, v. 0.1 essentially contains three parts: 1) link resolver or base URL; 2) the item being described, such as an article in a journal; and 3) the source or from where the user is coming; therefore, v. 0.1 contains information about the desired information object and two pieces of context: the source and the target.

“Generalizing the OpenURL Framework beyond References to Scholarly Works,” by Herbert Van de Sompel and Oren Beit-Arie

www.dlib.org/dlib/july01/vandesompel/07vandesompel.html

Although there was a private data section in v. 0.1 that allowed bilateral linking agreements, developers were also trying to convey other context in v. 0.1 in a nonstandard way. For example, developers might want to include context information not only about a user's institutional affiliations, but also about the user's method of authentication, such as Athens or Shibboleth. In other words, developers wanted to include additional user attributes, which could further define that user's context and affect the resolver's behavior. If the OpenURL contained information about a user's authentication method, then such authentication could occur in the magic behind the curtain, thus never bothering the user with the need to prove his or her affiliation.³⁰

Pesch, in a presentation at a September 19, 2005, NISO workshop in Washington, DC, (OpenURL and Metasearch: New Standards, Current Innovations, and Future Directions) elucidated that OpenURL v. 1.0 attempts to address the context limitations by introducing the ContextObject. The ContextObject, now the core of the OpenURL, can describe the user's context using the following elements: referrer, resolver, requester, referent, referring entity, and service type. Additionally, the ContextObject contains an administrative element that allows for items such as version control, character encodings, time stamping, and more. Pesch, in his presentation, gave the following examples of the six new elements:

• ▪ Referent: Item being referenced, e.g., the bibliographic reference in the full-text article;
• ▪ Requester: “User” making the request;
• ▪ Referrer: Service creating the link, e.g., where the user found the link;
• ▪ ReferringEntity: Item [that] contains the reference, e.g., the article in which the bibliographic reference was found;
• ▪ Resolver: Target of the link, e.g., the link server of the user's institution; and
• ▪ ServiceType: Desired services from the resolver, e.g., full text, ILL, abstract, etc.³¹

Ultimately, these new elements allow for a greater picture to be drawn of the user's context. Ex Libris's SFX product manager Nettie Lagace explained that because the OpenURL 1.0 standard is extensible, it allows the information transport about a requester and a referring entity as well as the details seen with v. 0.1 regarding the referent, i.e., the item being requested. It is important to note that simply because OpenURL v. 1.0 allows for these new contexts, it does not mean information providers are actually populating them with information.

Although the possibility now exists, the reality may be further into the future. Some new innovations have already occurred. Lagace noted the generalized OpenURL 1.0 standard enables providers to send better, more specific data about more types of ContextObjects, thus, linking capabilities have been extended to more entities. For example, SFX servers are now receiving 1.0-format OpenURLs for such items as dissertations, which allows Ex Libris to link to full-text dissertation databases and pass on the details about these documents to ILL servers and citation managers.³²

This example from Ex Libris, though, was not the typical answer from other link-resolver vendors. When asked how the OpenURL v. 1.0 standard has affected linking initiatives at Serials Solutions, and more specifically, how, if at all, Article Linker has changed with the release of OpenURL v. 1.0, J.R. Jenkins, the group product manager of Serial Solutions’ Article Linker/Central Search, replied: “To date the changes have been minimal [because] the vast majority of vendors send either 0.1 or hybrid metadata. Only a select few (Ingenta, for example) send pure 1.0 metadata.”³³ Jenkins comments were echoed in my conversations with other link-resolver vendors and content providers.

Diana Bittern, director of software product management, Ovid Technologies, Inc., noted, “We have received little interest [from] our customers for linking applications that require OpenURL 1.0 standard. One of the main drawbacks is that it's a far more complex standard specification than 0.1. We also find that both standards are lacking the ability to mark up lists of metadata elements (authors, genome codes, or CAS numbers) in the link request, which is something we currently can achieve by slight modification of the OpenURL 0.1 request.”³⁴

Additionally, Mike Hoover, senior linking and integration engineer at ProQuest Information and Learning, indicated that, until very recently, not all link-resolver vendors supported v. 1.0. Hoover noted v. 0.1 is still very functional and allows content providers to support the lowest-common denominator. Hoover went on to comment that, as more people begin to exploit the enhancements and features available in v. 1.0, there will be more need for content providers to upgrade.³⁵

The ContextObject is only one way in which OpenURL v. 1.0 further enhances its predecessor. Pesch elucidated that the OpenURL v. 1.0 also allows more flexibility, i.e., more choices in how the information in the OpenURL is represented, how the set of data is represented, and the vocabulary or set of elements used.³⁶ For example, in v. 0.1, only key value pairs were allowed; v. 1.0 allows for other physical representations such as XML, MARC, or Dublin Core. Necessarily, more options mean the possibility of greater confusion, so the new standard paves the way for the creation of an OpenURL registry (www.openurl.info/registry) in which developers can declare their intentions. This registry is, according to Pesch, the key to extending the OpenURL standard.³⁷ Prior to December 2005—as noted in an e-mail correspondence between Phil Norman and myself on November 2, 2005—the registry was managed by OCLC for NISO; a maintenance agency was to be named in December 2005 (which was after the time of writing).

The OpenURL registry contains the following entries for its framework: namespaces, character encodings, physical representations, constraint languages, ContextObject formats, metadata formats, transports, and community profiles; therefore, developers can register new formats and new sets of tags. For example, developers can register the format to describe a conference proceeding versus a patent versus a book. Again, information from Pesch's NISO workshop presentation, “Introduction to OpenURL,” elucidates: the “registry provides for discovery and extensibility” and the “profiles allow communities to define their needs and choices.”³⁹ The community profiles include the San Antonio Levels 1 and 2 (SAP1 and SAP2) as well as a community profile in trial use for Dublin Core.

NISO Workshop: OpenURL and Metasearch: New Standards, Current Innovations, and Future Directions, September 19–21, 2005, Washington, D.C.

www.niso.org/news/events_workshops/OpenURL-05-Agen-FINAL.html

In short, the registry and the official implementation guidelines (http://alcme.oclc.org/openurl/docs/implementation_guidelines/index.html) allow developers to flex their muscles and take the OpenURL into areas hence left unexplored.

The final main difference between v. 0.1 and v. 1.0 is that v. 0.1 was basically about describing an object and the user's context and then sending it as an “HTTP GET” request, thereby limiting what developers could do. On the other hand, v. 1.0 separates the ContextObject from the data transport. Pesch explained, in a 2005 interview, that OpenURL v. 1.0 becomes a container with six bits of context, which allows developers to use transport methods other than HTTP.⁴⁰

To put it simply, Oren Beit-Arie, in another 2005 interview with the author, emphasized the importance of separating the description (the ContextObject) from the transport method. For end-user purposes, or for system-to-browser communication, a developer may want to choose different transportation types but may not necessarily need to change the way in which the content, or ContextObject, is described. Beit-Arie, when discussing this “transportation,” also explained the developer needs to provide an address to the transport mechanism. Again, in simple terms, when a person mails an envelope, the envelope must have an address in order to be delivered, and once the enveloped is addressed, it will only be delivered to one specific place. If the description is tied to the transportation, then, for example, a content provider must create five envelopes containing the same content description for five users. If the description is separated from the transportation, the content provider can create the description of the item and store it; once the user is known, the content provider can then add the transport address—in linking terminology, the address is the address of the user's link resolver.⁴¹

Some transports for v. 1.0 look and perform very similar to v. 0.1, such as the Inline OpenURL over HTTP or Inline OpenURL over HTTPS. There are other transports available, however, that differ more dramatically from v. 0.1. These are available at the Registry for the OpenURL Framework (www.openurl.info/registry). For any developer wishing to implement the v. 1.0 standard, three resources are crucial reading: ANSI/NISO Standard Z.39.88-2004; Registry for the OpenURL FrameWork Z.39.88-2004; and The Key/Encoded-Value (KEV) Format Implementation Guidelines (URLs are listed in screened box on page 22).

Future Developments for OpenURL v. 1.0

Although some evolution of the OpenURL has occurred using v. 1.0, it remains to be seen how developers will change the face of linking with the new standard. When link resolvers were first introduced, they were like magic: they allowed libraries to enter data in one place and facilitate context-sensitive linking in their resources. To be blunt, any context-sensitive links were better than the sea of dead ends users might face in a linking environment that did not account for the appropriate copy. Now, at least in most libraries in the United States and in Canada, link resolvers are less magic than commonplace. Focus has moved to providing increasingly high-quality linking and linking to more than just scholarly full text.

Part of increasing the quality of links is the standardization of metadata, as well as the notion of content providers being good sources and targets. At the NISO workshop (OpenURL and Metasearch: New Standards, Current Innovations, and Future Directions, September 2005) Eric Hellman, founder of Openly Informatics and current director of OCLC Openly Informatics, gave a presentation entitled, “How to Be a Good Target.” It is encouraging to see content providers becoming more aware of how their internal linking syntaxes and linking policies affect those outside of their organizations. Hellman noted in his presentation that both syntax-based linking and database-based linking (such as CrossRef) are needed to serve the widest possible audience. Hellman encouraged content providers to document and publicize their syntax-based linking schemas. Hellman also advised content providers about how to make good CrossRef-based links and how to avoid bad links by publishing their holdings and being tolerant of errors.⁴²

On the other end of the spectrum, Proquest's Mike Hoover gave a presentation about how to be a good source. To allow content providers more information about becoming a source and/or upgrading to v. 1.0, he noted in his presentation that two of the common community profiles are the San Antonio Profile Level 1 (SAP1) and San Antonio Level 2 (SAP2). SAP1 uses key encoded values (KEV) and is widely implemented. SAP2 supports XML, but is not as widely implemented; SAP2 allows for the transportation of multiple ContextObjects. Hoover stated that link-resolver and metasearch vendors will increasingly use SAP2 as they further refine their products to integrate better and provide more accurate linking. He emphasized the need for quality metadata and, like Hellman, strongly encouraged content providers that are sources to provide clear, consistent documentation.⁴⁴

Registry for the OpenURL Framework

www.openurl.info/registry

OpenURL Framework Guideliness

http://alcme.oclc.org/openurl/docs/implementation_guidelines/index.html

ANSI/NISO Standard Z.39.88-2004

www.niso.org/standards/standard_detail.cfm?std_id=783

KEV Implementation Guidelines

http://library.caltech.edu/openurl/StandardDocuments/KEV_Guidelines-20041209.pdf

With v. 1.0, developers have more room to explore unforeseen possibilities. Some of these possibilities have already emerged, and to be sure, many more are just a glimmer of an idea in a developer's mind. Before further exploring the future of linking—including how developers are using the OpenURL to link beyond the full text of scholarly articles—however, this report moves to discuss what products are available for libraries to implement the OpenURL.

“How to Be a Good Target,” by Eric Hellman, and “Being a Good Open URL Source,” by Mike Hoover, both presented at NISO September 2005 Workshop: OpenURL and Metasearch: New Standards, Current Innovations, and Future Directions (URL below)

www.niso.org/news/events_workshops/OpenURL-05-Agen-FINAL.html