Following on from a previous post on innovation in libraries, I’ll focus on a single technology as a first example. It gets quite specific, but should be illustrative of how the market does not always manage to quite push things forward in the best interests of the customer.
OpenURL is a standard/ technology/ product that has been in use for over ten years in libraries. If you are not familiar with the term, its a way of getting a library reader to the online full text that their institution subscribes to, going one step beyond a DOI. When launched, it was seen as an innovative solution to a real problem, and like many good ideas was the brainchild of one individual.
OpenURL links contain citation metadata and are passed to an institutions ‘Link Resolver’, which queries its ‘knowledgebase’ of library subscriptions and directs the reader to the appropriate full text for them, usually via a pop-up menu.
Here is a much better fuller explanation. SFX and Serials Solutions 360 Link are popular Link Resolver products and provide central knowledgebases libraries can activate their holdings on.
OpenURL has never been massively sexy, but it continues to play a large role in online library services.
I would suggest it that it was a great idea in its day, but has since been hampered by a lack of innovation in its current presentation and approach. Some parts of the concept probably need a real rethink.
This post looks at the current state of OpenURL from the point of view of major stakeholders.
Reader interaction with a link resolver is typically through a pop-up menu (example). They tend to view this as part of the ‘paywall’, as it is often accompanied by a proxy server or federated access login. They may see this as an additional unnecessary step (‘why can’t I just click on the link and get to what I need?’).
Link resolver menus suffers from confusing terminology, and have been hampered by feature creep. They were originally intended to offer print alternatives to full text, something that is less necessary these days. Librarians have also tried to add other helpful links, which tend not to be so. Cambridge is as guilty of this as anyone and our supplier, Ex-Libris has offered a better lighter menu we really should adopt.
To get to the menu, readers have to click on a OpenURL button by a citation (the Cambridge one is branded ‘ejournals@cambridge’). I would suggest that readers find the presence of a button even when there is no full text confusing (see point 4 below). And why do we need to offer pop-ups in 2011?
If we could find a way to maintain the functionality of the SFX menu but in a more discreet fashion, it would be better for readers. Its’ an additional frustration step that in my opinion needs to go.
2) Library System vendors
OpenURL seems to remain on vendors’ radar as both a useful service and a profitable product. Ex-Libris seem to be folding the functionality into its new generation of resource management product. All seem to be investing in knowledge bases as management of subscription resources become more important.
Some are depreciating its importance to the end-user, Serials Solutions Summon is proposing index enriched URLs that know a customers supplier for a text and try not to bother them with a pop-up window, which seems sensible, assuming it works.
Following on from the previous point, Librarians are now heavily reliant upon OpenURL knowledge bases for a variety of back office functions. Due to this, currency of information in a knowledgebase is mission critical to libraries and should be pursued as a matter of urgency. We’ve seen some improvements in publishers and vendors sharing information updating (KBART). This is welcome, but I’m sure every vendor could do more. I speak to Librarians who would want a 48 maximum turnaround on getting this data updated.
Why? because it costs us money (lots). For every week or month a knowledge base cannot reflect our ejournal holdings accurately, some of our expensive subscriptions cannot be accessed via menus and A-Z’s, so we are effectively wasting our subs. When your ejournals budget is 6-7 figures long, this waste can add up quick.
If vendors or publishers were directly feeling this pinch rather than readers and librarians, I would imagine things may be different.
OpenURL linking itself is probably a necessary evil given the multitude of vendors and interfaces we have for A&I and full text. I doubt we will ever truly be able to offer ‘one search box to rule them all’ and will thus have to resort to’ glue technologies’ like OpenURL. What we really need is a better way to facilitate the linking, which brings me onto …
4) Database and ejournal publishers
OpenURL support has always been patchy with publishers. There are to my mind two major problems with the way OpenURL has been implemented by publishers.
1) Granularity of linking. Some will resolve incoming URL’s fine. Others not so. Some publishers will always drop the reader at a title page for the journal, rather than the actual article required. I assume they see OpenURL as an unwelcome form of deep-linking that bypasses their sites navigation. This impairs the experience for the end user, who assume they are getting a ‘straight to PDF’ button on the link resolvers’ menu.
2) Knowledge of customer holdings. One of my major problems with OpenURL has been the way its been supported in our subscription abstract/ citation databases, e.g. Web of Knowledge, Scopus etc. They tend to ‘spam’ a button by every citation result and force the reader to have to click on each one to see if the library really does have a full text subscription.
If your workflow involves checking every week for new research papers on a subject, this can get tedious really quickly.
Only Google Scholar has bothered to improve on the button, by harvesting our holdings from our knowledge-base directly and only showing a link when we have the full text. No other abstract/citation service has bothered to replicate this. Its not even innovation, just bothering to stay competitive.
A better solution
What bothers me is that it is technically trivial to do achieve this even without harvesting.
How? Using API’s and a bit of Ajax or even server-side code, we can easily step beyond the ‘openurl button’ and show holdings information from the link resolver directly in the citation results, along with some branding for the library that picks up the expensive tab for the full text.
All major link resolvers have API’s, the OpenURL spec itself supports XML for requests and responses.
Why don’t publishers do this? My deeply cynical thought is that as most sell full text as well as citation search services, they would prefer to sell you their copy of the full text alongside the citation.
They might even see OpenURL links as a means for competitors to push their full text into interfaces. Maybe by keeping things confusing with a generic OpenURL button, they hope that readers may get frustrated and start paying $30 for an article (24 hours only!) instead …
To make matters worse, Scopus and Science Direct can now pull in article recommendations from the excellent Ex Libris bX service directly and display it ‘in-interface’. Great stuff, so why can’t they do the same with our full text holdings from the Ex Libris SFX link resolver API?
This would be best for readers, and thus for librarians. Not sure how it would affect publisher profit margins though.
So here we have an example of a market driven innovation falling behind, a ‘gap’ between reader expectation/ current web technology and publisher business models. OpenURL sits uneasily between library, system vendor, publisher and the reader. In its current form, it will never truly satisfy anyone.