June 30, 2008

The Fundamental Mysteries of OpenURL

OpenURL

My colleague Andrew Houghton and I have been comparing notes lately and have come to some surprising realizations. Below are three mysteries that everyone who loves and/or hates OpenURL (not to mention the unwashed masses who have never even heard of it) should ponder deeply:

Everything is a Resource

Believe it or not, everything is a resource. I mean everything. The set of resources identified by URIs is merely an infinitesimal subset. Furthermore, every single URI that gets minted implies a unique resource. Even for a single resource (e.g. an image of a dog), the set of possible URIs (and thus implied unique resources) could easily stretch out to infinity (e.g. by appending a query string with a floating point rotation value).

Since OpenURLs are ultimately URIs, each of these likewise implies a unique resource. Confronted with a potentially infinite variety of OpenURLs, most Requesters will have no hope of recognizing that a single resource (aka Referent) stands behind them all. If this doesn't bother you, it should. Stay tuned for the solution...

All Operations are CRUD

I have long wondered why OpenURL doesn't require at least one ServiceType Entity the way it requires a Referent Entity. At the very least, why not mention the option of an implied default ServiceType? After all, Requesters are going to expect some non-random task to be performed when they resolve an OpenURL.

Suddenly, this makes perfect sense to me. An OpenURL can be understood by any agent (and not just those that are OpenURL-aware) to be a protocol-based absolute or relative URI for a web resource. In HTTP terms, the common operations performed on resources are POST, GET, PUT, and DELETE. Note that these operations are commonly referred to as Create, Read, Update, and Delete (CRUD). It would be odd and unnecessary to construct an OpenURL with a create, read, update, or delete ServiceType Descriptor that gets invoked via HTTP GET. This would amount to "tunneling" operations over HTTP that HTTP can perform natively. Even a search operation boils down to an HTTP GET operation on a resource URI. After all, a search service is "something" and, as argued above, "Everything is a Resource". HTTP GET is just the right operation to make it return a useful response.

Any belief that OpenURL supports operations other than CRUD betrays an OpenURL-bias that the non-OpenURL world will never buy into. If this bothers you (and it should), try to imagine instead that it is a good thing. Stay tuned for the solution...

Q6 "Binds" Resources and CRUD Operations

Since "Everything is a Resource", and "All Operations are CRUD", where does OpenURL fit in and what are its limits? The answers lie hidden in the OpenURL domain model. Stay tuned to find out who, what, where, why, when, and how...

Implications

These three principles can be applied to everything that happens on the Internet (and far beyond). For example, random agents can understand SOAP to be a set of CRUD operations on resources that are tunneled to a SOAP service resource via HTTP POST. A demonstration of this will have to wait, though. OpenURL already lies closer to the truth, so we'll start there...

Jeffrey A. Young
Andrew Houghton