Managing electronic resources in libraries involves a complex web of technologies and services, each with its own set of challenges. One such challenge is the intricacy of navigating paywalls to access a library's digital content. This section examines the complications that arise when accessing paywalled materials. We explore how technologies like OpenURL link resolvers can streamline this process and enhance interoperability between multiple services.


We take it for granted that we can seamlessly follow links to websites and webpages on the web, or do so without too much fuss. It gets more complicated when we want access to works that are behind paywalls, despite where such works have been found: search engines, bibliographic databases, OPACs (online public access catalogs), or discovery services. In these cases, direct links to sources identified in these services do not always work.

The issue becomes complex when a library subscribes to a journal or magazine. Access is often provided through third-party services, not just the publisher's default site. Example third-party services include bibliographic databases, like EBSCOhost or ProQuest. Also, libraries provide multiple discovery points and multiple ways to access the same works, such as through bibliographic databases with overlapping scopes. Bibliographic databases can tell us that an item exists when we search for it, but a library may not subscribe to the publication or the item might be in the stacks, stored off site or at another library altogether. These issues, along with the challenges presented by paywalls, necessitate additional layers of complexity, such as the use of proxy servers for user authentication, that make access more complicated.

Let's consider an example. The journal Serials Librarian is published by Taylor & Francis Online / Routledge, and has the following site as its homepage:

The journal is indexed in EBSCOhost's Library, Information Science & Technology Abstracts (LISTA) database and in ProQuest's Social Science Premium Collection (SSPC) database, among other places (e.g., it can also be found in Google Scholar, Google Search, a library's discovery platform, and more). This means that an article like the following can show up based on a query on any of the above platforms, even if none of these search or discovery platforms provide full text access to the article:

Brown, D. (2021). "Through a glass, darkly:: Lessons learned starting over as an electronic resources librarian. The Serials Librarian, 81(3–4), 246–252.

All these access points are good for the user, but they present a technological problem, too. That problem is: how do I link to the main source?

One way to know if our library provides access to the above source and others like it is through a link resolver. We see UK's link resolver in action when we see a View Now @ UK button or link. When we click on that button or link in a database like the above mentioned LISTA or SSPC, we trigger the link resolver, and that routes us through the library's discovery service. In LISTA, that link looks like this:

In Social Science Premium Collection, the link looks like this:$2f$$2fopenurl$2f01SAA_UKY$2f01SAA_UKY:UKY$3furl_ver$3dZ39.88-2004$26rft_val_fmt$3dinfo:ofi$2ffmt:kev:mtx:journal$26genre$3darticle$26sid$3dProQ:ProQ$253Alibraryscience$26atitle$3d$2526ldquo$253BThrough$2ba$2bGlass$252C$2bDarkly$2526rdquo$253B$253A$2bLessons$2bLearned$2bStarting$2bover$2bas$2ban$2bElectronic$2bResources$2bLibrarian$26title$3dThe$2bSerials$2bLibrarian$26issn$3d0361526X$26date$3d2021-11-01$26volume$3d81$26issue$3d3-4$26spage$3d246$26au$3dBrown$252C$2bDaniel$26isbn$3d$26jtitle$3dThe$2bSerials$2bLibrarian$26btitle$3d$26rft_id$3dinfo:eric$2f$26rft_id$3dinfo:doi$2f10.1080$252F0361526X.2021.2008581/MSTAR_2645781371/LinkResolver/1193?t:ac=2645781371/Record/D137B205B8D14795PQ/1

Clicking on either of the above links in their respective databases sends us to Primo, UK Library's discovery layer.

If we had clicked on EBSCOhost's View Now link, the Primo link will result in the following:,%20Darkly%22:%20Lessons%20Learned%20Starting%20over%20as%20an%20Electronic%20Resources%20Librarian.&sid=EBSCO:Library,%20Information%20Science%20%26%20Technology%20Abstracts:156075536&volume=81&pages=246-252&issn=0361526X&au=Brown,%20Daniel&genre=article&ID=doi:10.1080%2F0361526X.2021.2008581

Look closely at those links (scroll to the right to view their entirety), and you will see that the article's metadata is embedded in the URLs. Among other things, you can see the publication title, the article title, the author's name, the DOI, and more.

That metadata is used to trigger a search query in the library's discovery platform (at UK, that's InfoKat Discovery by Primo). It specifically initiates a GET HTTP Request, which is designed to request data from a resource/server, in this case InfoKat Discovery, using the metadata embedded in the URLs.

This is primarily the work of an OpenURL link resolver, which is designed to provide access to a target (main content) despite the source (where item was found) by initiating queries in an OPAC or discovery platform using the metadata embedded in a URL.

OpenURL is a technical solution to the paywall problem. It is designed to help users of electronic resources access a source in a library's collection based on a citation/record that the user discovered in a search result, an article's list of references, or wherever else the link resolver might show up. It is meant to work for all items in a library's collection, including print items, since print items have records in the catalog or discovery service, and those records have their own URLs.

Use Cases

Google Scholar Example

Let's consider a search scenario in Google Scholar. To start, users can affiliate themselves with a specific library through Google Scholar's settings. Once that affiliation has been set up, Google Scholar leverages a knowledge base (a structured database containing details about a library's collections) to facilitate access to paywalled content.

It works like this:

  • Metadata extraction: Google Scholar extracts the article's (or other content) metadata, which includes details such as the title, author, DOI, and publication year, from its database.
  • Administrative metadata: Additional metadata about the institution, such as an institutional ID number, is added to this information.
  • URL query formation: This collective metadata is converted into a URL query designed to search the library's collections through its discovery service.
  • User presentation: Users are presented with various target options for retrieving the article, or in some cases, they are taken directly to the full text (e.g., if only one target option exists in their library's collections).

The term target options refers to the different ways to obtain the article or acquire access to other content. These options may include:

  • Full text access from various and possibly multiple vendors or publishers. This is why a record in a discovery service may have multiple links to content.
  • Information about the article's physical location if available on a library's shelves.
  • Options to request the work through interlibrary loan.

To link Google Scholar to an affiliation:

  1. Go to
  2. Open Settings
  3. Click on the Library Links tab
  4. Search for your affiliation
    • e.g., University of Kentucky
  5. Add and save

Now when you search in Google Scholar, you should see View Now @ UK links (if your affiliation is University of Kentucky) next to search results that your affiliation has in its collections.

See Link Resolver 101 for additional details and this historical piece on link resolvers (McDonald & Van de Velde, 2004). Also, Alma provides Google Scholar documentation that is useful to read through. See also Google Scholar's documentation.

Consider conducting a basic keyword search in Google Scholar using the term electronic resources. If you are affiliated with a specific library, let's take the University of Kentucky (UK) as an example, you should see a View Now @ UK link next to at least some of the search results. An OpenURL, which we will dissect in detail later, contains the article's metadata and identifies Google as the source:

The original publisher of this article is Emerald, and the full text is available through Emerald eJournals Premier. This information is processed by Primo, UK's discovery and delivery service. Primo redirects our query to the UK Library's proxy service, OpenAthens (as of the summer of 2023; formerly it was EZProxy). After authenticating ourselves using our secure (we hope!) university account login, we gain access to the full text from Emerald.

Should alternative databases like EBSCOhost and/or ProQuest provide access, and not the original publisher (e.g., Emerald in this case), Primo would present us with options to select our preferred database for viewing the full text.

In scenarios where there is only one source to the content provided by the library, the transfer to Primo to OpenAthens to the Emerald full-text occurs swiftly, providing a seamless user experience.

Dissecting an OpenURL

Understanding the anatomy of an OpenURL can help us comprehend how metadata is transmitted and processed within library systems. As an example, let's dissect a specific Primo URL to identify its individual components.

The following Primo URL is an OpenURL link, which means Primo follows the standards of OpenURL. (See ANSI/NISO Z39.88-2004 (R2021) The OpenURL Framework for Context-Sensitive Services. It is composed of various fields and values that make up the metadata. For readability, I have broken up the URL into individual lines by metadata fields. The metadata fields begin after the openurl? keyword:

The link resolver technology, which operates in the background, translates the metadata to interact with appropriate library services. In this specific URL, the 'institution', 'vid', and 'sid' fields serve as administrative metadata that help to identify the institution and source information. The key fields used to retrieve the article are:

  • aulast: The author's last name
  • id: The DOI (Digital Object Identifier)
  • auinit: The author's first two initials
  • atitle: The title of the article

These fields play crucial roles in ensuring that the correct resources are fetched from the library's database, making the OpenURL an important element in providing access.

One feature of the above URL is Percent-encoding, a process used to encode URL-unfriendly characters, such as spaces, into a parsable format. Percent-encoding employs UTF-8 encoding, a common character encoding standard. Read about UTF-8 percent-encodings and the characters they correspond to.

In Case of Interlibrary Loan

We can see another instance of this within Primo itself. In UK's InfoKat, I search for the phrase electronic resources and filter by the WorldCat options from the drop down box to the right of the search box. By filtering for WorldCat options, I'm more likely to retrieve records that are not in UK Library's collections.

The first option is a work titled Electronic Resources. Selection and bibliographic control. Since this is not available via UK Libraries, I would have to request the item through interlibrary loan. When I do that, the link resolver triggers ILLiad, which is used for interlibrary loan. Note how the OpenURL looks much different here. Essentially, the OpenURL is contextual, and its context reflects the service being used (i.e., EBSCOhost, ProQuest, Google Scholar, Primo, Illiad, etc.) which determines the metadata elements in the URL. Note that some elements are empty (e.g., is an empty value for the date field versus rft.genre=book&, which holds the value book for the genre field).


Our readings this week by Kasprowski (2012), Johnson et al. (2015), and by Chisari et al. (2017) discuss link resolver technology, migration to new link resolver services, and methods to evaluate link resolver technology from both the systems and a user's perspective. It may not be necessary to learn how to hack your way through the OpenURL syntax, as I have above (or below: See Appendix A), or other aspects of link resolver URL formatting, but it is a good idea to acquire a basic understanding of how the URLs work in this process.

Let me re-emphasize that the key way that link resolvers work is by embedding citation metadata within the link resolver URL, including administrative metadata. This is another reason to have high quality metadata for our records, as our readings note. By implication, if we find, perhaps by an email from a library patron, that a link has broken in this process, it might be that the metadata is incorrect or has changed in some important way. Knowing the parts of this process aids us in deciphering possible errors that exist when the technology breaks.

For this week, see the ExLibres Alma link resolver documentation, which is the link resolver product used by UK Libraries. Let's discuss this documentation in the forum. I want you to find and explain other instances of link resolvers. Be sure to provide links to these examples and articulate ways the technology can be evaluated.

Documentation to read and discuss:

Link Resolver, Usage

Additional information

Appendix A

How I Enhanced Zotero by Hacking OpenURL

Since OpenURL compatible link resolver technology is partly based on query strings (more on this below), as we have seen, we can glean all sorts of information by examining these URLs: the query string component that contains the metadata for the source but also the base component that contains the vendor and institutional information and also the URL type. When I worked on this section, I was able to learn that Primo/Alma uses two URL types to request resources: a search URL and an OpenURL. We can see this the URLs. The base search URL looks like this:

The base OpenURL differs just a bit (see the end of the URL):

The base search URL appears when searching the university's discovery service. However, the OpenURL only appears when needed and during transit between the source and before reaching the target: e.g., after clicking on a View Now @ UK link and before being redirected to the full text version. I copied my institution's specific OpenURL when I clicked on a View Now @ UK link and before it redirected to the OpenAthens page.

My students often identify great problems to solve or are the source of great ideas. In a previous semester, one of my students in my electronic resource management class noticed that Zotero has a locate menu that uses OpenURL resolvers to look up items in a library. By default, Zotero uses WorldCat, but it can use a specific institution's OpenURL resolver. I had completely forgotten about this. When I investigated whether my institution was listed in the Zotero locate menu, I found that it was not nor was it listed on Zotero's page of OpenURL resolvers.

At the time, I didn't know what my institution's exact OpenURL was, but I was able to figure it out by comparing the syntax and values from other Primo URLs listed on Zotero's page of OpenURL resolvers. By comparing these OpenURLs, I was able to derive my institution's specific OpenURL (base component plus institutional info), which is:

I added that to Zotero, and it worked, and then I posted the OpenURL info to Zotero's forum, and they've added it to their OpenURL resolver page. If others are curious about how to add this info to Zotero, another library has created a video on this. The directions cover adding a specific OpenURL to Zotero and on how to use Zotero's Library Lookup functionality.

Appendix B

A Basic URL

I mentioned query strings above. Theses are a part of a URL that include instructions to query engines, database, or websites (like Wikipedia). The parameters (i.e., search terms) are part of a query string, too. It's also important to understand the base part of a URL (link) because the link in link resolver is the part of the whole process. A URL for an article can looks like this:

This URL contains the following components:

  • https:// : indicates the secure hypertext transfer protocol (HTTP)
  • www : indicates the subdomain
  • emerald : indicates the second level domain name
  • .com : indicates the top level domain

Under a standard web server configuration, the rest of the URL (after the .com) indicates a possible directory path to the location of the article on the Emerald web server, but it's likely that the content management system used by Emerald does not necessarily map to directories or folders on their servers.

The DOI (digital object identifier) for this article is embedded in the above URL and is specifically 10.1108/10650740510632208. The DOI is composed of a prefix and a suffix. The prefix includes the following elements:

  • 10 : signifies the DOI registration agency, which is always "10" for DOIs managed by the International DOI Federation (IDF)
  • 1108 : the registrant code that distinguishes the organization that registered the DOI (e.g., publisher, data center, library)

The suffix refers to the following element:

  • 10650740510632208 : a character string (in this case, of numbers) that refers to the article. This string is created by the registrant

The DOI itself can be used to create a permanent URL for the above work be adding a to the beginning:

Readings / References

Chisare, C., Fagan, J. C., Gaines, D., & Trocchia, M. (2017). Selecting link resolver and knowledge base software: Implications of interoperability. Journal of Electronic Resources Librarianship, 29(2), 93–106.

Johnson, M., Leonard, A., & Wiswell, J. (2015). Deciding to change OpenURL link resolvers. Journal of Electronic Resources Librarianship, 27(1), 10–25.

Kasprowski, R. (2012). NISO’s IOTA initiative: Measuring the quality of openurl links. The Serials Librarian, 62(1–4), 95–102.

Additional References

McDonald, J., & Van de Velde, E. F. (2004, April 1). The lure of linking. Library Journal. Library Journal Archive Content.