Blind as a bat
A few weeks ago I posted OpenURL 1.0 for Reptilian Brains by Jeff Young. Jeff has continued to think about this problem and has come to the conclusion that the whole world is an OpenURL resolver, it just doesn't know it (yet). Well, not quite, but here are his latest thoughts.
--Th
In a previous blog entry, I argued that OpenURL wasn't nearly as difficult to implement as people believed. My naïve belief was that programmers would eagerly embrace the potential of interoperability, as long as the barriers weren't too high. The frustration expressed in that article was the result of learning that "two lines of code" was too high a price to play for those benefits. Programmers don't care about "slightly harder"; they want "significantly easier". Most standards don't have much of a chance against this reality.
As it turns out, however, that's not the only thing I got wrong in that article. I was also wrong about OpenURL being only "slightly harder". I now believe that OpenURL is, in fact, "significantly easier". So much so, that every web service in existence is already 100% OpenURL-compatible. "But what about rft_id and url_ver=Z39.88-2004", you might ask?
What I finally realized (just this morning) is that these are artifacts of specific applications (what OpenURL calls CommunityProfiles). My narrow-minded understandings of OpenURL lead me to believe that all applications should (ideally) conform to existing URL construction patterns (what OpenURL calls Transports). I had no excuse for this prejudice. The OpenURL standard defines a registry where instances of CommunityProfiles and Transports can be defined and expanded. OpenURL doesn't dictate anything. It is merely a model to describe and (optionally) develop systems.
Think of it this way. Every web server in existence is a 100% compatible OpenURL resolver. No exceptions. In OpenURL terms, the URL construction they use to invoke their services is called a Transport. Just because no one ever bothers to register their construction in the OpenURL registry is another matter. It's not required. The point is, they could register it without changing a single line of code. The same is true for CommunityProfile, which is intended to describe the application in detail. Just because no one bothers to do this doesn't alter the fact that they could do so without changing a single line of code.
So, why was I so committed to the transports that were used as examples in the standards document? I don't know. Why didn't anyone point this out to me? I don't know.
Jeff
Comments