The State-of-the Art: Link Resolvers in the Trenches

Citation

Felker, K. (2003), "The State-of-the Art: Link Resolvers in the Trenches", Library Hi Tech News, Vol. 20 No. 9. https://doi.org/10.1108/lhtn.2003.23920iaf.001

The State-of-the Art: Link Resolvers in the Trenches

Kyle Felker

Librarians have long struggled with the dilemma of where to send students who want full-text of a specific article and don't know where to find it. With access to new databases all the time, and constantly shifting coverage in established databases, it's impossible to say for certain just where a digital copy of an article might lie. Services such as Serial Solutions, while a definite improvement, have not entirely solved this problem, since students can't link directly from the citation they found to the material they need.

OpenURL and the new link resolver products based on it offer the promise of a solution to what has been dubbed "the appropriate-copy problem." But promise and practicality can be worlds apart. In addition to offering a brief introduction to openURL, and an overview of the new marketplace for link resolver products, this article will also report on a managed discussion involving libraries running such products, and the issues they identified in setting up and maintaining such systems.

OpenURL and link resolvers: a brief primer

A traditional URL is much like a street address in that it identifies a particular location. A browser following a traditional URL is somewhat like a person who has been given a street address and told, "Knock at this door and ask for file X. Then bring it to me." If the browser can manage to find the right number on the right street, and if anyone answers the door, and if the person who answers happens to know where file X is, then the browser brings back file X and all is right with the universe. Unfortunately, there's an awful lot that can go wrong there, leading to the dreaded "404 page not found" message. Because the browser has neither the contextual information on what it's looking for, nor the intelligence to make guesses about what it should do if the item is not where it's supposed to be, 404 errors are annoyingly common.

An openURL, in contrast, is much more like a picture of what's being searched for. Instead of containing a dodgy street address, the OpenURL contains information such as the title of the item, its creator or author, or a unique number, such as an ISSN, that identifies what's being looked for. Instead of passing this information directly to the browser (which wouldn't know what to do with it), link resolver systems pass the openURL to a special computer which knows all about what subscriptions your library has and what material exists in each subscription. Using criteria generally provided by the library, this smart computer decides where to send the user to get what they need, thus "resolving" the description into an actual link to whatever was asked for.

This is only the tip of the iceberg. Depending on how a resolver system is set up, how complex it is, and what information is passed by the source in the openURL, a link resolver can not only connect a person to what they asked for, but offer a whole range of peripheral services such as linking to information about the creator of the item, reviews of the item, or linking to other items that are similar to the item asked for.

Notice my use of generic language such as "thing" or "object." While most link resolvers are being used to provide students with access to full text articles in databases, pundits are already theorizing about applications for the open Internet. The standard itself is written to be extremely flexible and to convey any type of information about anything. It's conceivable that link resolver systems might, at some point in the future, provide better searching and access to anything out there in Webland.

Link resolver systems have three main components:

1. 1.

   Link sources: a source is anything that can recognize that a user has a link resolver available to him or her, displays a special button the user can click on, and can construct and send an openURL to the users resolver. A source might be your catalog or a remote database. Many of the larger information vendors, such as Ebsco and Gale, and most of the larger library OPAC systems, are capable of being sources.

2. 2.

   Link targets: Targets can't construct OpenURLs, but they can be linked to from openURL systems. Link targets can also be things that aren't databases at all, like an ILL form for material that's not owned or accessible. It's generally much easier to be a target rather than a source, and as you would expect, the list of OpenURL targets is much longer than the list of sources.

3. 3.

   The resolver: This is the heart of any OpenURL system. The resolver is a special server that can take the information in an openURL, match it against the library subscription information, and return a link to the material asked for. The subscription information is contained in a database, which is often called the "knowledgebase," and a resolver is only as good as the information in its knowledgebase. Some resolvers are also capable of storing criterion on how many and what kinds of links should be displayed, for example, a well-designed resolver might be able to take instructions like "if you have to choose between sending people to Ebsco and the homepage for the online journal, send them to the homepage."

Resolvers can be local, meaning the actual link resolver software and knowledgebase resides on a machine owned and operated by the library, or remote, meaning the entire system resides an a server owned and administrated by the link resolver provider. There are trade offs either way: buying and maintaining computer equipment can be expensive, but contacting the vendor every time you need the system tweaked can be annoying.

Issues from the trenches

The LITA Human Machine Interface Interest group hosted a managed discussion on link resolvers and link resolver products at ALA Annual in Toronto. What surprised me most at first was that despite low conference attendance numbers, the room was packed to capacity. Obviously, the choice of topic was a good one. In attendance were librarians from all over the country, many of whom had OpenURL systems and had been operating them for years, and some who had no system but were interested or looking to buy (my own institution falls into this category). We also had many, many vendor representatives from companies developing or marketing link resolver products, such as Ebsco and Serials Solutions.

Major issues that surfaced were:

Data problems

Often, data passed by a source does not match data kept in the knowledgebase, or vice versa. This means that sometimes, even when an item is accessible, the user of the system never sees a link to it, or receives a link that doesn't work. The problem seems to be twofold: first, there are a lot of opportunities for faulty data to mess up the system. One example of this cited by an attendee is that of ISSN numbers, which may be incorrect in the knowledgebase, the catalog, the database vendor's information, or all three. If an incorrect ISSN is passed as part of an openURL by a source, the knowledgebase may fail to match it against its subscription information. Or, if the ISSN is wrong in a target, like a library catalog, the resolver may create a link that uses the ISSN that leads to a "page not found" error.

The other part of the problem is the resolver itself. Given that the data involved resides in so many places, and is thus likely to be incorrect somewhere, it's a great advantage if a resolver system can try to match multiple pieces of information passed before it gives up on creating a link. If the resolver doesn't do this, there is a great likelihood that even if the item is accessible, the user will never be directed to it. Not all resolvers are this savvy.

All of this also points to the fact that maintenance of the information contained in the knowledgebase is tremendously important. Most libraries represented indicated that their collection development, electronic resources, or serials librarians were responsible for this, although at least one institution seems to employ a part time staff member who does almost nothing but care for the knowledgebase.

Article-level linking

In order to be a viable target for an openURL system, a database or information resource needs to have the capability for direct liking to full-text articles. Otherwise, students following links to the database will be dumped at a generic search screen. While many databases have this capability, there are still some large and important databases, such as Academic Universe, which do not. This is a problem not only for link resolver systems, but interlibrary loan, electronic reserves, distance education, and many other aspects of online teaching and information provision. Librarians need to put pressure on database vendors to provide direct linking capability. The vendors present made some interesting suggestions about using peer pressure where economic incentive won't work, as in "you know, all of your major competitors offer this functionality … why can't you?"

Just how many of your own databases offer direct linking, and thus can be targets, should be a consideration when looking to buy one of these systems, as well as how many are capable of being a source.

Customization

In the past, some vendors of openURL products have used their own market speak in user interfaces without allowing the library the option of customizing things like button texts with messages that were more meaningful to students. The vendors present indicated that we had been heard on this issue, and that most companies are striving to offer libraries as many customization choices as possible. Usually this translates to control over the text that appears on buttons and choices offered to the public, as well as customization of the knowledgebase in terms of what links are selected and presented and in what order.

Assessment

I was also a bit surprised by how little assessment of their own systems attendees seem to have done. While most resolver systems keep some level of statistics, I got the distinct impression that librarians at most institutions were not looking at them, nor at other potential indicators such as ILL requests for items owned or accessible by the library, which would presumably decrease when such a system was in place.

Some other things mentioned:

• •

  It's important to understand that a resolver system is not a discovery tool. For the most part, it won't help a researcher with a topic explore available information on that topic (that's more along the lines of a portal or metasearch engine). What it is is a support tool, intended to help people who already know exactly what they want get to it. This makes portals and link resolvers complementary tools, not competitors.

• •

  Since so much effort goes into the knowledgebase, it's a good thing when it can serve multiple purposes, for example, outputting lists of journal subscriptions that can be posted to Web pages or shared with faculty.

• •

  Since, for the most part, link resolver systems are designed to be transparent, they present a challenge for marketing to students. Most libraries seemed to assume that once the system was put into place, students would find it and use it on their own.

The marketplace

The semi-finalization of the openURL standard has led to a minor explosion of link resolver products. As with any new market, we can expect that some of these products will endure while others will go the way of the dodo. Rather than listing the major players, in this section I will concentrate on some general observations on the market as a whole. If you are interested in listings and comparisons of specific products, then I recommend "OpenURL Breed Link Resolution Options" by Priscilla Caplan in the June 2003 issue of Smart Libraries Newsletter. Be aware that even in the very short time since that issue came out, some things have changed (some of the products listed as being only remote or locally hosted are now offering a choice, for example).

It's important for librarians to understand that OpenURL is currently a trial NISO standard. What that means is that it's possible (although perhaps not likely) that the standard will change radically in the future, which would affect all the products based on it. Link resolvers are built on "bleeding edge" technology, which means this market is likely to see some major upheaval in functionality and price in the next few years. Early adopters, beware!

Many, many companies, such as Innovative interfaces or Fretwell Downing, are concentrating on marketing their link resolver products as part of a suite of digital solutions including, typically, portal software. For libraries that don't already have a portal, this could mean a discount on both products compared to what they would cost separately, as well as better potential integration between the two products. For most, though, the option to purchase the resolver software separately does exist.

Pricing differences are huge. Most rely on some formula that takes institutional size into account, most often via FTE, and this is charged whether the software is locally or remotely hosted. This mirrors a growing trend in the software industry to license software on a subscription basis rather than sell it outright, probably as a means of both generating more revenue and maintaining more control over how the software is used. Irregardless, prices for these products can vary even for the same product depending on what your FTE is, whether you are part of a consortia, and whether or not you are purchasing the product as part of a suite. I have seen quotes for several products for our own institution that ranged from a few thousand ($3,500 is the lowest I've seen) to $80,000, for a resolver from one of the major vendors packaged with several other products.

An entire article could be written about selecting a link resolver for your institution. Rather than go through that here, I'll recommend Caplan's article again, with the addition of the following things to think about:

• •

  How (or will) the resolver deal with any existing remote authentication system you are already using? Will students from off campus be able to access resources using the resolver?

• •

  Who will care for the knowledgebase? Your systems people? Your collection development people? How easy to use is the knowledgebase interface, and how much training and knowledge of subscription information are required?

• •

  If you don't already have a portal and think you might want one, then purchasing a link resolver is a good time to discuss it. Do you want a portal? Would you be interested in purchasing it as part of a package?

• •

  How many of the databases you subscribe to can serve as sources? How many can be targets? Most link resolver vendors have lists of both on their sites, and it's worth taking a hard look at these and matching them against your own subscriptions.

As libraries rely more and more on electronic information, link resolvers will only become more popular. This makes understanding what they really do and how they really work that much more important. Together with portals, resolvers share the potential to provide seamless access to the world of knowledge, but like portals, the reality can fall short of the promise.

Kyle Felker (kyle.felker@ccmail.nevada.edu) is the Web Manager at the University of Nevada, Las Vegas.