OpenResolver: A Simple OpenURL Resolver
This article provides a brief introduction to the deployment and use of the OpenURL [1] [2] by walking through a few simple examples using UKOLN's OpenResolver, a demonstration OpenURL resolution service [3]. The intention is to demonstrate the ability of OpenURL resolvers to provide context-sensitive, extended services based on the metadata embedded in OpenURLs and to describe the construction of simple OpenURL resolver software. The software described here is made available on an opensource basis for those who would like to experiment with the use of OpenURLs in their own services.
The OpenURL is an important technology in the development of shared, open, reference linking services and is seen as one of the key 'access' components of the developing DNER information environment architecture [4]. The DNER enables people to 'discover', 'access' and 'use' a wide variety of resources. OpenURL resolvers can locate various services associated with a resource, including services that allow the user to request and access it - they can help to solve the 'appropriate copy' problem, namely:
Having discovered a resource, how is the user provided with access to the most appropriate copy, given user and institutional preferences, access rights, cost, etc.?
OpenURL
The OpenURL provides a mechanism for encoding a citation for an information resource, typically a bibliographic resource, as a URL. The OpenURL is, in effect, an actionable URL that transports metadata, or keys to access metadata, for the object for which the OpenURL is provided. The target of the OpenURL is an OpenURL resolver that offers context-sensitive services based on that metadata. The OpenURL resolver is sometimes referred to as the user's Institutional Service Component (ISC).
The citation is provided by either using a global identifier for the resource, for example a Digital Object Identifier (DOI) [5], or by encoding metadata about the resource, for example title, author, journal title, etc., or by some combination of both approaches. It is also possible to encode a local identifier for the resource within the OpenURL. In combination with information about where the OpenURL was created, this allows software that receives the OpenURL to request further metadata about the information resource.
An OpenURL comprises two parts, a BASEURL and a QUERY. The BASEURL identifies the OpenURL resolver that will provide context sensitive services for the OpenURL. The BASEURL is specific to the particular user that is being sent the OpenURL - it identifies the user's preferred OpenURL resolver. In many cases this will be the resolver offered by the institution to which the user belongs. Services that embed OpenURLs in their Web interfaces, for example in their search results, must develop mechanisms for associating a BASEURL with each end-user. One way of doing this is to store the BASEURL in a cookie in the user's Web browser, another is to store the BASEURL along with other user preferences.
The QUERY part can be made up of one or more DESCRIPTIONs. Each DESCRIPTION comprises the metadata attributes and values that make up the citation for the resource. A full breakdown of the components of the DESCRIPTION is not provided here. See the OpenURL specification for full details [6].
Here is an example OpenURL:
http://resolver.ukoln.ac.uk/openresolver/?sid=ukoln:ariadne&genre=article &atitle=Information%20gateways:%20collaboration%20on%20content &title=Online%20Information%20Review&issn=1468-4527&volume=24 &spage=40&epage=45&artnum=1&aulast=Heery&aufirst=Rachel
In this example the BASEURL is <http://resolver.ukoln.ac.uk/openresolver/>, the URL of the UKOLN OpenResolver demonstrator service. The rest of the OpenURL is the QUERY, which is made up of a single DESCRIPTION of an article entitled 'Information gateways: collaboration on content' by Rachel Heery. The article was published in 'Online Information Review' volume 24.
OpenResolver walkthrough
It is recommended that you try out the following examples while reading this article, using your preferred graphical Web browser, for example Internet Explorer or Netscape. Open a browser window and navigate to the following URL:
http://www.ukoln.ac.uk/distributed-systems/openurl/
You should see a Web page like the one below:
Imagine that the right-hand side of the page contains three items in a course reading list or forms part of the output of a search against a bibliographic database of some kind. The right-hand side of the page is dynamic, in that the image and target URL associated with the button next to each of the three listed items is dependant on the preferred OpenURL resolver of the current end-user. Notice that the first time you visit this page you will not have a preferred OpenURL resolver set, so the buttons indicate 'No resolver'.
The left-hand side of the page allows you to set your preferred OpenURL resolver. Notice that in this example, you are only given a choice of two resolvers: UKOLN's OpenResolver service and the sample SFX resolver offered by Ex Libris [7].
In this demonstrator these two bits of functionality (setting your preferred resolver and displaying some citations) have been combined into a single Web page. This is unlikely to be typical however. OpenURL aware services (i.e. services that can generate OpenURLs) are more likely to offer a single place on their site where you can set all your user-preferences, including your preferred OpenURL resolver.
An OpenURL aware service, such as the Web page above, needs to maintain knowledge of each user's preferred OpenURL resolver. In this example, the BASEURL is stored as a cookie within the end-user's browser. However, other approaches can be used, for example storing the BASEURL at the server along with other preferences associated with the user.
Select the 'OpenResolver' button on the left-hand side to set your preferred resolver. The link associated with this button calls a CGI script called cookiepusher.cgi (based on the Cookiepusher developed by Ex Libris [8]). The cookiepusher.cgi script takes two arguments, the 'BASE-URL' of an OpenURL resolver and a 'Redirect' URL. The script sets a browser cookie containing the BASEURL and then issues an HTTP redirect to the specified URL. In this case the redirect simply results in the OpenURL demonstrator page being loaded again (but this time with a cookie in the browser).
Notice that the buttons associated with each of the items on the right-hand side have now changed to indicate that your browser has stored a cookie containing the BASEURL for the OpenResolver service. In this example, these buttons are generated dynamically by some JavaScript in the Web page. In many services they will be generated dynamically by the Web server that is serving the page, perhaps as part of delivering some search results. The code used to generate the buttons in this example consists of the following JavaScript embedded at the top of the page:
<script language="Javascript"> <!-- //////////////////////////////////////////////////////////////////
// taken from SFX version 3.0
//
// version check
var version = 1;
var appname = "";
if (navigator.appName.indexOf("Netscape") >= 0) {
appname = "ns"; }
else if (navigator.appName.indexOf("Explorer") >= 0) {
appname = "ie"; }
if (navigator.userAgent.indexOf("Mozilla/2") >= 0) { version = 2; }
else if (navigator.userAgent.indexOf("Mozilla/3") >= 0) {
version = 3; }
else if (navigator.userAgent.indexOf("Mozilla/4") >= 0) {
version = 4; }
// Read cookies
function loadCookie(name) {
var allcookies = document.cookie;
if (allcookies == "") return "";
var start = allcookies.indexOf(name + "=");
if (start == -1) return ""; start += name.length + 1;
var end = allcookies.indexOf(';',start);
if (end == -1) end = allcookies.length;
return allcookies.substring(start,end);
}
// Read the user-OpenURL cookie that has been set by the
// information system. Give the BASEURL parameter the
// value of the user-OpenURL cookie
BASEURL = unescape(loadCookie("user-OpenURL"));
// Provide the service identifier - sid - to be included in the
// OpenURL
// sid = 'ukoln:';
// Define a function that will open the OpenResolver menu screen
// when the OpenResolverButton is clicked.
// object_info refers to the OBJECT-DESCRIPTION part of the
// OpenURL.
function openWin(object_info) {
var url = BASEURL + "?" + "sid=" + sid + "&" + object_info;
window2 = window.open(url , "OpenResolverMenu" ,
"location=no," +
"status=yes," +
"menubar=no," +
"scrollbars=yes," +
"resizable=yes," +
"width=460," +
"height=420");
if ((version>2 && appname=="ns")||(version>3 &&
appname=="ie"))
window2.focus(); }
// Define a function that will insert the OpenResolverButton and that
// will hyperlink the OpenResolverButton with the appropriate URL.
function OpenResolverButton(object_info) {
if (BASEURL.length < 4 && BASEURL.indexOf("http:") < 0) {
document.write("<img src=\"noresolver.gif\" alt=\"No OpenURL resolver
configured\" align=\"right\">");
return false;
}
var url = "javascript:openWin('" + object_info + "')";
var anchorStr = "<img src=\"" + BASEURL + "/sfx.gif\" alt=\"Resolve
OpenURL...\" border=\"0\" align=\"right\">";
document.write(anchorStr.link(url));
return true;
}
// // taken from SFX version 3.0 /////////////////////////////////////////////////////////////////////////////////////// // -->
</script>
The following code is then used to generate each button:
<script language="Javascript"> <!-- OpenResolverButton("genre=article&sid=ukoln:&atitle=Information%20gateways:%20co llaboration%20on%20content&title=Online%20Information%20Review&issn=1468-4527&vo lume=24&spage=40&epage=45&artnum=1&aulast=Heery&aufirst=Rachel"); // --> </script>
The OpenResolverButton() is passed the QUERY part of the OpenURL and is called once for each button on the page. It combines the QUERY with the BASEURL extracted from the cookie and generates some HTML for the button.
Select the top OpenResolver button on the right-hand side. A new, smaller window should open up:
This window is the output of the OpenResolver OpenURL resolver service. We'll take a look at the contents of the page in a moment. However, before we do that it is worth noting that everyone reading this article and trying out these examples will be seeing the same thing at this point. Instead, imagine a scenario in which there are lots of OpenURL resolution services available. For example, many institutions may begin offering their own resolvers. There may even be personal OpenURL resolvers available. In such a scenario, each person reading this article is likely to want to set a different resolver BASEURL, and each person is therefore like to be presented with a different set of resolved services at this point. This is the real strength of the OpenURL approach - resolvers provide users with a set of context sensitive services that are tailored to their personal and/or institutional preferences, needs and access rights.
Now, back to that window. The Web page it contains is the output of some relatively simple OpenURL resolver software. The software has taken the metadata embedded in the OpenURL and used it to point to other services:
- The DOI in the OpenURL has been resolved to provide a URL for one of the on-line versions of the article. (Note, that although the article is mirrored by UKOLN, the resolver points to the original version in the US. Future version of the OpenResolver software will attempt to resolve the DOI into more than one URL, and to offer the most appropriate URL for any given end-user first.)
- The main words in the article title have been used to form the basis of searches against well-known Web search engines.
- The journal title has been used as the basis for a journal search of the University of Bath OPAC (note this service may not be available off-campus) and COPAC.
- Finally, the first author's name (the OpenURL metadata only includes the name of the first author) is used as the basis of a Google search.
In order to do this, the OpenResolver software must be able to extract metadata (as text strings) out of the OpenURL and plug it into the URLs for other services. Services that are compatible with this approach are sometimes referred to as being SFX-aware. When the UKOLN OpenResolver was first developed, the University of Bath OPAC was not SFX-aware. There was no way of creating a Bath OPAC URL containing the ISSN for a journal or the ISBN for a book - all OPAC use was session-based, with journal titles only discoverable by searching. This has now been rectified. However, there is another, more general, problem. The OpenResolver software simply takes the ISSN out of the OpenURL and inserts it into a University of Bath OPAC URL. It has no real knowledge of whether that journal (or a particular journal issue) is actually held by the University of Bath library or not. Links are created 'just in time', with no guarantees that they will actually point to anything useful. As a partial solution to this problem, the DNER architecture proposes that OpenURL resolvers should be able to obtain holdings, and other, information from an 'institutional profile' service, indicating which journals are held by which libraries.
Go back to the first window and select the second OpenResolver button (the one alongside the Heery citation).
Now select the bottom link on the OpenResolver output for that OpenURL. This link does a Google search for 'Rachel Heery'. A third window will open up displaying the results of this search:
Close this window and return to the first window. Select the third OpenResolver button. Take a look at the OpenResolver output:
Select the first Google link on the page. This performs a search of Google based on the words in the book title:
Selecting the 'Bath OPAC' link displays the record (or records) in the University of Bath library OPAC that matches the ISBN encoded in the OpenURL metadata for this book:
Finally, selecting the 'Amazon' link brings up the Web page for that ISBN in the Amazon (UK) [9] online catalogue.
OpenResolver software
As indicated above the OpenResolver software is relatively simple - probably too simplistic to form the basis of real services. However, the source code is freely available under a GNU Public License [10]. It is written in Perl and may well form a suitable basis for more significant OpenURL resolution service development.
In the main, the software simply extracts portions of metadata from the OpenURL and reformats those text strings within the URL for another service. For example, it extracts the ISBN from the OpenURL and reformats it as an Amazon 'query' as shown below:
DOI resolution is slightly more complex than this, because the DOI has to be resolved into a URL. Although in theory it is possible to resolve DOIs using the Handle service [11], the current OpenResolver software takes the simpler approach of encoding the DOI as a normal DOI URL, issuing an HTTP request for it and then trapping the resulting HTTP redirect from <http://dx.doi.org/>.
Summary and conclusions
The following diagram summaries the delivery of the OpenResolver demonstration service described above:
- The OpenURL demonstration page is served by the UKOLN Web server.
- JavaScript in the page obtains the BASEURL of an OpenURL resolver from a cookie from the user's browser and uses it to generate the buttons next to each citation on the page.
- The user selects one of the buttons and a new window in their browser is directed to the OpenURL resolver of their choice.
- The OpenResolver software constructs a list of services based on the metadata encoded in the OpenURL.
- The user selects one of the services listed in the OpenResolver output. A third window is opened and directed to the chosen service.
This has been a very quick tour of the functionality offered by the OpenResolver and by the OpenURL more generally. There are signs that the OpenURL is already generating significant interest and a number of publishers, intermediaries and other service providers are committed to its support [12]. The OpenURL is currently moving through the NISO fast-track standardisation process. It is anticipated that there will be some changes to the OpenURL specification as standardisation takes place. In particular, it is intended to widen the applicability of OpenURLs beyond the bibliographic arena. While there are obvious applications for providing access to books and journals through libraries, bookshops and other document deliver services, the OpenURL appears to also offer a simple mechanism for linking together bibliographic and other services in interesting, novel and useful ways.
References
- OpenURL Overview
<http://www.sfxit.com/openurl/> - Open Linking in the Scholarly Information Environment Using the OpenURL Framework
Herbert Van de Sompel, Oren Beit-Arie D-Lib Magazine, Volume 7, Number 3
<http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html> - OpenURL demonstrator
<http://www.ukoln.ac.uk/distributed-systems/openurl/> - The DNER Technical Architecture: scoping the information environment
Andy Powell, Liz Lyon
<http://www.ukoln.ac.uk/distributed-systems/dner/arch/> - The Digital Object Identifier
<http://www.doi.org/> - OpenURL Syntax Description
Herbert Van de Sompel, Patrick Hochstenbach, Oren Beit-Arie
<http://www.sfxit.com/openurl/openurl.html> - Ex Libris SFX Web pages
<http://www.sfxit.com/> - SFX: Cookiepusher document
<http://www.sfxit.com/openurl/cookiepusher.html> - amazon.co.uk
<http://www.amazon.co.uk/> - OpenResolver source code
<ftp://ftp.ukoln.ac.uk/metadata/tools/openresolver/> - Handle System
<http://www.handle.net/> - SFX: OpenURL-enabled resources
<http://www.sfxit.com/sources-list.html>
Author Details
Andy Powell
Assistant Director, Distributed Systems and Services
UKOLN: the UK Office for Library and Information Networking
University of Bath
E-mail: a.powell@ukoln.ac.uk