November 15, 2006
I gave a presentation at DLF last week on Q6 and the OpenURL object model. The PowerPoint slides can be found here.
Jeff
|
|
Simple OpenURLAugust 15, 2006 The OpenURL specification defines 4 types of Descriptors:
Alas, this is one of the few OpenURL abstractions that aren't included in the OpenURL Registry. This is unfortunate, because it might indicate an unnecessary bias towards the citation-linking heritage of OpenURL. No doubt, the need for Descriptors to be language- and platform-independent was a limiting factor in the composition of this list. Fortunately, Private Data was included as a catch-all category. Still, though, I can imagine at least one more category that would have been useful. I'm not sure what label to give this, but basically it is a mime-type value coupled with a Base64-encoded byte array. This would be a strange looking beast to be sure. Nevertheless, OpenURL has great potential for creating machine-to-machine protocols and I could transport all kinds of stuff that way and expect a very high level of comprehension on the other end. I have to admit, though, that this is a quibble. If I really wanted to do this, I could shoehorn it into a Private Data Descriptor and publish this usage to the community using such a profile. BTW, working for OCLC, you might expect the Metadata-by-value and Metadata-by-reference to be particularly dear to me. Not true. What gets me excited about OpenURL is the potential for Identifers (URIs). That's where I see the real magic happening, not just for libraries but to infinity and beyond. Lastly, this blog entry only considers OpenURL Descriptors from a language- and platform-independent perspective. This makes sense from a web-based client-server perspective, but there is more that could be said about Descriptors once the server receives the request (or for applications that use an embedded OpenURL resolver). At that point, the OpenURL implementation no longer needs to worry about language- and platform-independence. Hmm. Maybe I should stop here for a while before crawling any farther out on this limb. August 14, 2006 OpenURL defines an abstraction for "Transports" that specifies the way an OpenURL request is to be formulated. The OpenURL spec go into detail about six of them:
The kindest thing I can say about them is that they work (apparently). Less fortunately, they are ugly and confusing. The main problem is that they assume that the entire ContextObject should be manifested in the structure of the "ContextObject Representation". But why would you want to pass in a Descriptor for the ReferringEntity when the server could get something useful and reliable from the HTTP 'Referer' header? And why should I trust the Requester Descriptors when my server has a perfectly good authentication/authorization mechanism built in? And what does it mean to pass in Resolver Descriptors? Do you want the resolver processing the request to perform the service directly or delegate it to one of the Resolvers in the list in some magical way? I had trouble making sense of this for the longest time. It finally dawned on me that a better way to conceptualize Transports was as the application module responsible for transforming an incoming ContextObject Representation into a normalized and enriched ContextObject Representation to be used internally. For example, the Transport class might get the HTTP 'Referer' header from the HTTP request and add it to a ReferringEntity container object before handing it off to the service class for processing. Likewise, it might invoke an authentication/authorization mechanism, and store the information from that in a Requester container object. Again, the same goes for Resolvers, which could be stored in a local database as is done for the OCLC OpenURL Resolver Registry Gateway. In theory, there could be applications where it makes sense to represent all these Entities explicitly in an externalized ContextObject Representation, but I can't believe these cases would be typical. Fortunately, we are not limited to these six Transports with all their baggage. Because they are registered components, we are free to invent new ones as we see fit. In fact, there is no limit to what Transports can look like. I could even go back to all the web applications I created before OpenURL came along and register Transports for them, without changing a single line of code. I understand that the cause of interoperability requires developers to agree to use common Transports, but I can't believe that the original six will prevail as the Transports to beat all Transports. August 7, 2006 The Q6 blog exists to describe a simpler way to understand and use OpenURL 1.0. The name Q6 refers to the fact that six simple questions convey the essence of the OpenURL model:
OpenURL has features that go beyond these Q6 equivalencies, but this mapping should be more than enough to support the vast majority of web service applications. Jeff 2006-08-16 Update the interpretation column of the table 2006-08-17 Altered the table row for "When". My interpretation was faulty |
Categories
Monthly archive
|
