Rethinking the role of an OpenURL link resolver

I think we should rethink the role of an OpenURL link resolver, for our patrons and our digital services for them, and for internal library tech infrastructure. We should be asking a bit more of such software than we are, and utilizing it more fully.

To address that, first we need to ask, from several perspectives: What is an OpenURL link resolver anyway?

The naive librarian might answer “It’s that thing that knows what full text we license, and directs users there.” This, I will suggest is far too limited.  On the opposite end, Jeff Young might suggest that, well, taking account of the full power and generality of OpenURL, your link resolver can do just about anything you can think of when it comes to web services. This, I think, is actually too abstract and far out. Here I’ll be taking a middle ground, talking about the sort of link resolver we have now, one that responds to citations to scholarly materials with services for users–but rethinking an expanded role for such a service.

Basic Technical Definition

An OpenURL link resolver is software that takes a scholarly citation formatted as an OpenURL and gives the user various things they can do with this. Access full text, make an ILL request, get it from the library stacks, etc.

So the Umlaut software sometimes has been called a “link resolver front end”, because it is used in concert with SFX backing it up, but in fact Umlaut is a link resolver. It takes an OpenURL and returns services.  It just doesn’t have it’s own built in functions for keeping track of what we license, or for generating links into most of our licensed content. It relies on SFX (also a link resolver) for that. But it’s still a link resolver.

But okay, why does any of this matter? Next let’s ask, what can a link resolver do for us, what in fact is it’s role? Sure, “that thing that there’s a button for in our licensed databases that you click on and it gives you full text”. But if we generalize our conception of this role just a bit, we can see that there are many more benefits to be realized.

From the outside: The electronic front door to the library

A tool that takes a scholarly citation and tells you what your library can do with it–that’s your libraries electronic front door—and there should be a path to it from other websites your patrons use.  Sure, many of our licensed resources provide a path to this ‘front door’.  Just a tiny bit, websites we don’t pay for are trying to use this ‘front door’—Google Scholar for instance.

But why stop there? All over the web, our patrons are looking at citeable resources that our libraries can help them obtain, or do things with. Shoudn’t each of them link to the libraries ‘electronic front door’, our link resolver? Looking at a book on Amazon? Link to the link resolver to see if the library has that book in print, has an eBook, or provide ILL or purchase-request services otherwise.  Let the user save the citation to a library-provided reference manager service too, while we’re at it. Looking at a movie on imdb?  Reading an article on nytimes.com?  The possibilities are endless.

Of course, most of these services don’t provide links to our link resolver, as Google Scholar does. Perhaps some can be persuaded to, but the real possibilities are in a browser extension like LibX. LibX adds links to external websites, without those external websites needing to participate at all, whether they like it or not.

The current LibX as typically configured doesn’t send users to the link resolver very often. Why? Becuase most commercial link resolvers can’t do anything very useful with most citations!  If it’s not an electronci copy in the link resolver knowledge base, you’re out of luck. But shouldn’t the link resolver look up whether the item is in print on the catalog for the user, and put that information right on the page without any other clicks? Aren’t there all sorts of other useful things the link resolver could do?

This was a large part of the motivation for Umlaut, making the link resolver a succesful and welcoming ‘electronic front door’, letting the user know, right away, with the library can do for them with that citation.

As a future project, I plan to customize LibX to point to our link resolver a lot more often than it typically does, taking account of the fact that we have a more powerful link resolver. Even add support for more websites that LibX doesn’t currently support, based on surveys of our patrons and what web sites they use.  And no, I don’t like the idea of relying on a browser extension either, but: our users use stuff all over the web that we can help them with. We need to integrate the library in their work flow all over the web. A powerful link resolver that can function as an ‘electronic front door’ combined with an extension like LibX is the best solution I can think of.

Inside our infrastructure: A known item service provider

So, looking at it from another point of view, what’s the role of an OpenURL link resolver? Taking a citation for a known item, and providing services for it. Aren’t there all sorts of places in our library-provided digital environment where we have known items, and there are services we can provide for them? (Services from telling the user if we have it and where it is in the stacks or electronically, to ILL, to public access digital copies at Google Books or the Internet Archive, etc. Maybe even tell the user if the local public library down the street has it, even if our academic library doesn’t?)

We have a variety of seperate software interfaces that present ‘known items’–that present particular scholarly citations. The OPAC, federated search, reference management, others in the future.  There’s often going to be a feature that we want in all of them–say, integration with Google Book Search to advertise GBS availability of a known item being presented.  It is inefficient and hard to manage to add the same functionality multiple times in multiple places.

Instead, we should recognize that the link resolver is the piece of software that provides ‘known items’ services, and when functionality is implemented once in the link resolver, it should be automatically ‘vended’ to all of our other systems in a ‘service-oriented’ approach. (I am less concerned with the formal definition of a ‘Service Oriented Architecture’ (SOA), then I am with the philosophy behind it). How can this be done?  The link resolver software needs to offer appropriate APIs to allow this functionality to easily be vended. When we want new ‘known item’ services, we need to think first of the link resolver when deciding where to add it (and we need either the ability to add such plugins to our link resolver ourselves, or get our vendors to add such functionality). And we need our other systems to be capable of ‘subscribing’ to these centralized vended services.

Umlaut was written with this in mind too. It offers a full suite of APIs, including some very easy to use javascript-snippet-embed type APIs (ala LibraryThing or GoogleBooks, but much more powerful).

So where do we go from here?

Soon, once I’ve deployed some things locally, I’m going to write another post advertising some new features in Umlaut that are practical applications of these principles, maybe they will convince you yet further. But if you’re already convinced, what can you do about it?

You can try to get your link resolver provider to add features making it a suitable ‘electronic front door’, or if your link resolver allows you to write plug-ins, maybe you can do that.   You can insist that your link resolver have an API so it can act as a ‘service oriented’ vendor of known-item services.  You can start building things on top of those APIs to start treating your link resolver in this ‘service oriented’ way.

Or you can think about adopting Umlaut. We adopted and developed Umlaut precisely because we thought it was the best way to meet these goals. If you have a link resolver with an API, Umlaut can be made to work with it in concert, but improving it’s nature as an electronic front door (with all the value added Umlaut features already written, and those we will continue to write), providing “service oriented” friendly APIs suitable for easy integration into your other known-item-providing interfaces.

For some reason I have had no luck at all getting people to seriously consider joining the Umlaut effort, and I’m not sure why.  If you have any feedback as to why there has been little Umlaut adoption (even the institution that originated it has given it up, leaving only me), that would be interesting to me.

But stay tuned for a demonstration of what these principles have led to in Umlaut.