Current Style: Standard
OpenURLs
Compiled by: Robert Bley, Ex Libris, December 2011
What are OpenURLs for?
The OpenURL concept was invented at the end of the 1990s to help address the problem of seamless access to full text and other resources. The OpenURL is now a NISO standard (Z39.88-2004) which lays out a universally understood syntax to improve access to high quality material. It has increased in popularity with information providers and with librarians as the quantity and complexity of scholarly electronic resources has grown. OpenURLs provide linkages to “target” resources (such as full text articles, library catalogues or other services determined by the library to be appropriate and available to the user). The user needs to start within an OpenURL enabled “source” (usually an abstracting and indexing service, full text journal service, library OPAC or metasearch, or federated search system). That source service will display an OpenURL button or link (usually branded by the library) that takes the user to a dynamically constructed menu of targets, built by the link resolver on the basis of a knowledge base of the library’s print and electronic full text holdings and the library’s preferences for the display of other relevant services (e.g. pay-per-view and document delivery) to end-users. See Figure1.
Figure 1
Some terminology explained
The Link Source needs to be OpenURL-enabled and can be anything from an abstracting and indexing service to e-journal or e-book site, OPAC or an open access repository. The “source” service provides the bibliographic record that is used for generating an OpenURL.
Each OpenURL source needs to be told the domain name (or “transport”) of the user’s OpenURL resolver. This is something that each institution running an OpenURL resolver will need to inform all of their “sources” of. Most sources also allow institutions to customize the text and/or the buttons that appear in their own OpenURL sources i.e. to encourage end-users to click on the buttons by giving them an idea of the purpose of such buttons or links.
NB: In the UK, it is possible for academic institutions to register their resolver just once via EDINA’s OpenURL Router service (see http://openurl.ac.uk/doc/ ) – although institutions will still need to inform each of their OpenURL sources about their choice of link text and/or button design.
Examples of different button designs can be found at the URLs listed later in this factsheet.
The Link Resolver (also known as a Link Server) is the hub of the service, as it is within the link resolver’s knowledge base that rules are contained for extracting metadata from the source OpenURLs, and for deciding which “targets” (end services) to display and how to construct deep links to those targets.
Examples of rules might be “if full text is available, don’t display other options”, or “if full text is available from target A, do not show target B”, “if no full text is available, check for print holdings in the library OPAC, and/or show an inter-library loan form” and so on. Information professionals can localise their server to match local subscriptions and other local preferences such as links to inter-library loans.
Link resolvers exist primarily to solve the “appropriate copy” and “context-sensitive” linking problems. By taking account of the user, and his / her rights as an individual or member of an institution with access rights to resources, OpenURL software presents the user with appropriate linking options and prevents them seeing dead or broken links, or links that they are not entitled to take. Link resolvers enable information professionals to provide users with a higher level of electronic library service because they are able to direct their users to the sites the library knows are appropriate to the user.
The targets displayed to the user are the ones that are relevant to him/her as a member of their institution, and are therefore called “context sensitive” links. This means that when a user clicks through from a source, the resolver will then provide a menu of options pertinent to the user. This could be a full text target or a link to the library catalogue (perhaps directing them to the printed journal) or to an inter-library loan request form if the item is not held by the institution. Most OpenURL resolvers also allow libraries to set up other targets, and libraries have been quite inventive in this respect. For example, some libraries have set up “find news stories on this subject” targets that take the article title metadata received from the OpenURL source, places that metadata in the “search” box of a news site and executes a search there. Others have set up targets that send the author metadata (received from an OpenURL source) to citation databases (to look up impact factors etc.).
How do they work?
When a user clicks on the OpenURL button within a source, the source service puts the “transport” (which indicates the domain name of the institution’s link resolver) together with the metadata for the record they were looking at (called the ContextObject). For example, in the case of a journal article, the ContextObject might include the ISSN, volume, issue and page notation.
An example would be:
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
Where …. <http://resolver.ukoln.ac.uk/openresolver/>, is the URL of the UKOLN OpenResolver demonstrator service (i.e. the transport). The rest of the OpenURL is the ContextObject, which is made up of a single description of an article entitled “Information Gateways: collaboration on content” by Rachel Heery, published in 'Online Information Review' volume 24, pages 40-45.
The URL is sent to the library’s OpenURL resolver (wherever it is hosted - it need not necessarily be within the library or its host institution). The resolver will then use a source parser to extract the relevant metadata elements from the URL. The link resolver then checks these data elements against the library’s holdings and the rules the library has defined. The resolver will then show a menu of options to the user designed by the information professional and based on the library’s subscription range and preferences. The menu options also allow the information professional to push their favourite services to the top of any list or to exclude certain resources.
The list of “targets” displayed to end users can include both OpenURL-enabled and non-OpenURL-enabled services. To be a useful target, a service should ideally have a deep-linking syntax that takes the user to the object (e.g. full text journal article) (s)he is interested in. Link resolvers contain target parsers that enable the link resolver to construct such deep-linking URLs “on the fly”, with the correct metadata parameters (e.g. volume, issue, page, issn, doi, chapter number, or other identifiers required by the target service) inserted in the correct places in the URL for each target. Most link resolvers are pre-populated with target parsers for the most popular academic information services, OPACs and publisher sites, and many also have tools that allow library and information professionals to construct their own target parsers.
Most link resolver providers will also maintain information about the standard aggregated journal and e-book packages, so that libraries no longer need to monitor which content falls into and out of such packages. In the case of packages where libraries have a choice about the titles and backfiles etc, it is usually possible to upload the relevant data into the resolver from Excel or similar files received from a subscription agent or publisher, or generated “in-house” by the library.
In essence, the information professional can decide which elements of metadata are sent to which target services under which circumstances. For example, the library could send the “author” metadata to a citation database to check the author’s impact factor, or send the “title” metadata to Google or to a news website (to check for news stories about the subject the article is about), or all the metadata to pre-populate an inter-library loan or document delivery service’s request form. What is contained on the context-sensitive menu of linking options that appears after the user has clicked on an OpenURL button is entirely under the library’s control.
How do users recognise the service?
Most libraries brand their OpenURL service to ensure that it is recognized as relevant by their users. Some examples of button and menu designs can be found at http://sfx-demo.exlibrisgroup.com:3210/demo/menu
How does the link resolver know who the user is?
Link resolvers assume that authentication has taken place before the user reaches the link resolver’s menu. Resolvers typically discern a user’s provenance by IP address, or from other parameters such as cookies passed onto them by OpenURL sources.
How do link resolvers work with resource discovery systems, and with Google?
Both GoogleScholar and Windows Live Academic, and most metasearch and vertical search systems are capable of being both OpenURL sources and also link resolver targets. GoogleScholar can be configured easily to use a link resolver, by using the “scholar preferences” option on the site.
Federated search and vertical search systems hugely increase the number of available OpenURL sources. Adding a title or resource to such a system means that it effectively becomes OpenURL-enabled, even if the original publisher wasn’t so enabled.
Some link resolvers bring added-value to vertical search and federated search systems, by allowing users to narrow-down their search results to “full text only” or “peer-reviewed articles” only. SFX – for example – has an API that allows search systems to “know” which articles they can allow users to “jump” straight to (without a linking menu), and also records in its knowledgebase a “peer-review indicator” which library search and other search applications can make use of.
The following sites provide guest access to Primo (library search solution site), within which, you will find OpenURL / SFX buttons (link resolvers): http://pinboard.in/u:ExL/t:Primo.
How are OpenURLs different from DOI links?
Digital Object Identifiers are a way of providing a method for persistent identification because, although the information about an object may change over time, including where to find it, the DOI will not change. Therefore DOIs are useful for preventing “dead” or “broken” links. By giving digital objects (such as articles, e-book chapters and so on) unique and persistent identifiers, DOIs ensure that the user only needs to know the DOI of an article (or other object) in order to be able to track down its current location(s).
However, the user may still not be entitled to link to that location / those locations without having (for example) paid for a subscription, or without being a member of an institution with a subscription.
OpenURL resolvers therefore act as the go betweens with DOI registries such as CrossRef (see http://www.crossref.org/03libraries/16openurl.html for example) in order to be able to ensure that a seamless context sensitive linking experience is provided to users. This is done in two ways:
1. By accepting incoming OpenURLs that contain DOIs. Link resolvers work with the CrossRef database to find out which article (or other object) a DOI refers to. They can then work out the correct target services for obtaining the actual object, based on the user or their affiliation.
2. By looking up the DOI for an article (or other object) where it is needed in order to construct a URL for a target service.
Who is in the market for providing OpenURLs services?
There are around 10 commercial link server providers and a few home grown ones. At the heart of all of them is the “knowledge base” (though not all vendors use this terminology) which may require some work to localise with a library’s physical and electronic holdings. A useful comparison of some of the available services can be found at:
What are the Benefits of OpenURLs?
OpenURLs enable information professionals to help users (a) by pointing them to the correct places for obtaining what they need, and (b) by suggesting further services that might help them in their research. Link resolvers also help to clarify duplications in collections. Some link resolvers also allow the download of MARC records for e-resources contained in packages the library subscribes or provides access to. This enables population of the library OPAC with e-resource title information (usually with the MARC 856 field pre-populated with OpenURLs) without a large cataloguing overhead.
Link resolvers do require some on-going local administration. However, most link resolvers allow easy upload of data received from publishers, aggregators and other parties and systems, and help to automate the tracking of the content in aggregated packages, and can therefore actually help to reduce the library’s workload. Moreover, link resolvers can also form the basis of e-resource management systems.
What else do link resolvers do?
Most link resolvers also encompass title-listing utilities such as those illustrated at http://sfx-demo.exlibrisgroup.com:3210/demo/azdemo
Some link resolvers are now growing to include elements of e-resource management functionality, such as providing tools for aggregating and analyzing COUNTER usage statistics from publishers.
SFX also includes a utility developed from mining SFX usage logs around the world – the bX article recommender service (see http://sfx-demo.exlibrisgroup.com:3210/demo/bXdemo ).
What does the future hold?
The next generation is likely to involve the use of latent URLs where users can choose their own resolvers via such services as COINS (ContextObjects in Span) which allow the embedding of bibliographic data into html. Further details are available at http://ocoins.info
The OpenURL framework (Z39.88-2004) opens the door for:
- Extending OpenURL use to non-bibliographic resources
- More granular services for individuals.
Most OpenURL services at the moment work at an institutional level, that is to say, the options presented to a user are usually based on his/her institutional affiliation. Possibilities now exist, through a variety of means, to present options based on an individual’s preferences. For example, the Shibboleth authentication framework allows very granular authentication information to be passed to link resolvers.
The Z39.88 standard also allows the transmission of OpenURL information within XML messages (this is largely done through URLs at the moment). XML transport will allow for further developments such as, for example, the transmission of OpenURL metadata in RSS feeds. The other main area of development is the continuing extension of the range of available sources and targets. Crucial to this is growing pressure from the library and information community upon publishers and other resource providers to become OpenURL sources, and to allow deep-linking (so that they become useful targets).
Work is also underway on developing standards to deal with the situation where some articles in a journal issue are free to access and some are subject to a publisher "paywall" or subscription.
Work is also at an advanced stage to integrate SFX functionality into wider "next generation" library management systems.
Where can I go for more technical information?
Useful resources include:
The OpenURL Framework Standard http://library.caltech.edu/openurl/Standard.htm
D-Lib Magazine http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html
ExLibris http://www.exlibrisgroup.com/sfx_openurl.htm
Other useful sites
OpenURL listserv http://listserv.oclc.org/archives/openurl.html
GetCopy http://www.edina.ac.uk/getcopy/
And some light reading…..
The myths and realities of SFX in Academic libraries. Wakimotea, Jin Choi, Walker, David S and Dabboura, K.S (2006). The Journal of Academic Librarianship 32 (2) March 2006 pgs 127-136
The report of a threefold study to answer questions on the effectiveness of SFX (a particular product) in an academic setting.
Pdf Version:
