Access always leaves me with at least one major shift in perception that I need to chew on for a while. This year it came, not unexpectedly, from Dan Chudnov: we need to merge our metasearch engine and our OpenURL resolver.

This fits with some recent incidents in which the resolver I manage failed to resolve because of incomplete metadata from more peripheral sources of OpenURLs: citation managers like RefWorks and Zotero. Citation management weirds the metadata, as far as OpenURL is concerned. Dates intended for human consumption don’t get parsed properly, and our resolver often needs a date and not just a volume number to determine availability. This is a serious problem, because your service looks very bad if a user exports a record from an e-resource to their citation manager, clicks the OpenURL button, and doesn’t get sent back to the place they know has the text. You don’t want to be told it’s unavailable when you just saw it a couple of clicks ago.

When the metadata is inadequate, what should have been resolution becomes search. Annette Bailey’s LibX demonstration showed some imaginative use of search to supplement resolution: sending the user on an article title search in Google Scholar, and then generating an OpenURL from the citation found there. Resolving and searching are the poles of a continuum, and where you find yourself depends on the quality and granularity of the metadata in your OpenURL. Give me good detailed metadata and my resolver should nail it for you first time; give me vague or faulty metadata and my search service should kick in to help you find your path. Ross Singler’s Ümlaut would enhance your metadata from other sources, the metasearch service would provide you with links to attempt different searches (like article title), and so on. Crucially, you shouldn’t have to choose in advance which service you’re going to use for a given full-text quest. Hence the merger.

This will make the resolution process more reliable, but also more complex, at least in the hard cases. This brings us to Roy Tennant’s complaint that the resolver menu is an irritating waste of a click for the user who just wants to get to the full text. In the simple cases, he’s right; in the hard cases, the menu is our only chance to give the user the expanded range of options that may be required to find the full text. The menu becomes an application rather than a list of options, and the user is engaged in an operation rather than passively following a link. Until our resolution services become much more reliable than they are now for the hard cases, I don’t think we can do without the menu.

In a merged system we run the risk of snaring the user in more loops: when we give more options, and try to do smart things to tweak the metadata before we send the user out to explore the trails we’ve blazed, they may end up clicking more OpenURL buttons and circling back with slightly different metadata each time, leading to slightly different options. The circles might be vicious or virtuous, who knows. I think the menu helps with this: when users know that clicking an OpenURL button always brings up the familiar menu, they’ll be less confused than they would be if it sometimes sends them directly off to something that is usually, but not always, the full text of the article they wanted. It will feel like repeating a Google search with different terms until you get what you want.