Recently I was interviewed for a podcast episode that might (hoping it indeed is published! [Updated 2/16, 5:30pm: yep, and here it is, and there goes the news about my new job...]) soon be heard by a lot of people. The topic was OpenURL, and why it's both so exciting and so frustrating to everyone who dives down into it.

I've been particularly frustrated with OpenURL lately. Just when efforts like COinS are starting to pay off (c.f. new Wikipedia cite templates, worldcat.org, new Wordpress plugin from Zotero, Zotero itself, and LibX), it feels like the door to wider use and acceptance of COinS specifically and OpenURL in general remains welded shut.

Don't take this the wrong way - I remain a huge OpenURL fan, including the whole vision that led to the ANSI/NISO Z39.88-2004 standard, even if that standard turned out to be way too complicated. I've been a fan of this way of doing things since we added multiple linking paths to the now-defunct jake project in early 1999, so we could link users from bibliographic references on the web into the books and journal articles the way your library has best set you up to do so, in pretty much an OpenURL-0.1-compatible way, even before we ever heard about OpenURL. (It was, after all, obvious to have a bunch of HTTP GET fields with names like [title, spage, volume, issue, issn, etc.].)

And I'm not saying we need to do away with OpenURL. I think instead that we need to recontextualize what it is we think OpenURL is for, and to do so in a way that focuses on the common use case of service linking on the web today. And I think we need to avoid dogmatic adherence to the Z39.88 standard, since we all mostly think it's overwrought anyway.

Let me try to explain it this way. Have you noticed those little clusters of links next to stories at NYTimes.com, or at the end of blog posts, or in reference databases, or on journal sites? These little blocks of links are popping up all over the place. What they are, in general, is "a list of the functions you can do from here, given the thing you're looking at now, depending on who you are."

New York Times service links.

Blyberg.net weblog service links.

Pubmed.gov service links.

JAMA service links.

Citeseer service links.

Google Scholar service links.

This, my friends, is dynamic service linking, in a nutshell.

(And, yes, I do mean "in a nutshell" as in "ooh, ooh, help, I'm trapped in a nutshell, get me out of here.")

I believe that this analysis maps *exactly* to the vision for OpenURL specified in the documents that led up to the ANSI/NISO Z39.88-2004 standard that nobody can actually read. They nailed it - they knew this was coming, and they were right, and here it is, all over the place, on the most popular sites on the web.

But there are two major problems with this analysis.

First, all of these diverse sites publishing useful service links for their own materials have *no* idea that I'm a Yale University person and that *my* library's OpenURL resolver is over here, yes, please, thank you very much. This means that there's no public, cross-site workflow for getting out from most of these sites' own concepts of what "context-sensitive links for me for this content object" what mean back into what Yale's library thinks should be useful links for me. Nor is there a clear workflow for me to get back out from a Yale resource to these online, not-at-Yale items. This is a fatal flaw in the current state of how we both conceive of and implement OpenURL solutions in libraries today (which is to say, not a fatal flaw in the model, just how we use it now).

Until we address this flaw in our current thinking, and bring this wider world of web resources and their own notions of service links and our traditional, more narrowly defined research library workflows into some kind of common system, we'll never see the full vision of OpenURL realized.

Secondly, and this is perhaps a bit less practical, but no less important, but I think the notion of "context-sensitive" linking does itself have a basic flaw. If you've studied finite automata or linguistics and know what language parsing is all about, "context-sensitive" might ring an alarm for you. "Context-sensitive" grammars tend to be significantly computationally harder to work with than "context-free" grammars. (If you're not familiar with this distinction, see the Wikipedia entry for Chomsky hierarchy.) Do you know how the "natural language query" problem remains mostly unsolved? Well, think about the difference this way - most human languages are context-sensitive, whereas most computer programming languages are context-free.

What we've done with the OpenURL model and how we use it in libraries today is to design a standard around our unusual, more complex cases (dealing with weird bibliographic references). The workflow we have applied to OpenURL is context-sensitive in that the publisher needs to recognize my network address, and needs to then redirect to my institutional resolver, and that our institutional resolver needs to be pre-configured with our holdings information, and the outgoing links from our resolver needs to be aware of my network address again as I go out there to get the thing I wanted in the first place. Without all of this preceeding context-setting, the workflow breaks, so our context-sensitive worldview simply requires all of it.

In the meantime, sites applying the more common, simpler cases (dealing with web links) have essentially adopted the entire OpenURL model but without so much as saying so. That blog engine doesn't care what my network address is, and doesn't know whether I have accounts at the endpoints of the digg and del.icio.us links at the bottom of the blog post. It'll send me there just in case I do, and at the moment of need, just in time, if I need to identify myself to digg, or to whatever the target link might be, I will, if I have an account. But not before. Digg doesn't need to know that I'm a TimesSelect subscriber. The New York Times doesn't care that I use unalog, not del.icio.us. This whole scenario does not depend upon - and thus performs none of - the context-setting of our library research and licensed resource workflows.

The computational aspect of it doesn't bail out if you don't have a del.icio.us account - del.icio.us just doesn't let you in, but I can still get there if I want. In the heavier-weight scenario, I can't even figure out where I might want to go through my OpenURL resolver if my institutional context isn't sniffed out by the original remote resource, because I never even get to the OpenURL resolver in the first place.

I think I'm starting to see a better way to address all of this. This post is already pretty long, though, so I'll just state the objective for now.

The goal of rethinking OpenURL, I think, should be to reimplement the same original OpenURL model of dynamic service linking as - in the typical case - a context-free workflow. The instant we do that conceptually, we see how unified all of this really could become. It gives us librarians something to offer the nytimes.coms and diggs of the world: a singular framework for mixing and mashing service links for diverse sites independent of who we all are and what we know about each other.

Then, to address the more complicated context-sensitive research workflows we hold so dear, we simply define a context-free way to hook into that workflow, so if some arbitrary transaction needs it, it can hand us over into it, but *not* until we have to have it.

I'm not sure who said it first, but there's a librarianly spin on the old Perl paradigm I think I heard at code4libcon or Access in the past year: instead of "making simple things simple, and complex things possible," we librarians and those of us librarians who write standards tend, in writing our standards, to "make complex things possible, and make simple things complex."

That approach just won't cut it anymore.

Coming soon: a concrete way forward.