Latent OpenURLs in HTML
Openly Informatics has published a draft
proposal for Latent OpenURLs in
HTML. The idea is to deal
with OpenURLs that crop up in an unauthenticated context, where the
server doesn’t know who the user is and therefore doesn’t know what
link-resolver to point the OpenURLs at. The solution, building on the
ideas of Dan Chudnov and Jeremy
Frumkin, is very
simple: the link is identified as an OpenURL by including
class="Z3988" in the anchor, and the href contains only the query
string, starting with the question mark. It would be up to some other
service to insert the address of the appropriate link resolver. This
would facilitate the development of autodiscovery systems, along the
lines that Chudnov and Frumkin have charted. The proposal is to use
version 1.0 of the OpenURL
standard, which could easily be
downgraded to the syntax of version 0.1 by services that needed to.
Openly’s plan differs slightly from what Chudnov and Frumkin had
proposed
in their paper: Openly embeds the OpenURL fragment in the href of an
anchor, where Chudnov and Frumkin had placed it in a div, thereby
displaying the query string to the user (if no autodiscovery service
intervenes to replace the div with a link dynamically). The only
significant difference is how they would degrade for users who don’t
have an autodiscovery service: the Openly user would get a
normal-looking but useless link, the Chudnov/Frumkin user would get a
rather cryptic display of metadata that probably contains no
break-points and therefore might stretch the page horizontally beyond
the limit of the browser window. I think I would prefer the former, but
the work that the autodiscovery service has to do would be trivial in
either case, so perhaps we should try both. (Chudnov and Frumkin also
propose an RDF-style format as an alternative).
What external services will insert the address of the appropriate resolver? Maybe browser plugins like the one I prototyped or the far more advanced work of Ross Singer, maybe proxy servers like EZProxy, maybe your RSS reader (we could start putting OpenURLs in blog postings!), etc. The important thing, as Chudnov and Frumkin point out, is that it should put the choice of resolver into the hands of the user, not the publisher.
Actually, the idea of a div or a span (per Dan and Jeremy's original article) was given up a while ago in favor of using empty anchors. http://curtis.med.yale.edu/dchud/resolvable/ explores the ideas a little more realistically than in their original paper (a revised paper, based on this work, will come out in the Spring issue of Ariadne. There's still a difference. The "Appropriate Resolver" page really only addresses OpenURL v. 0.1 urls. The tension between the simplicity of v 0.1 and the versatility of 1.0 is something that really needs to be worked out. You can see some of your ideas in the last paragraph already have some traction.
Thanks, Ross, clearly I've fallen way behind on this stuff. I see that I missed an important feature of Openly's proposal, that the anchor should be empty and therefore invisible until it is activated by the external service. And I tried putting a discoverable OpenURL in this comment, but WordPress replaced the
relattribute with "nofollow", so it didn't work. One other implication of this is that sid's are going to proliferate in all kinds of ways. Any attempt to derive usage stats from our link resolvers will be affected.I think that if you can't implement the openurl "rel" attribute in wordPress, that's a problem!
[...] laquo; Ajax and Autocompletion OpenURLs in Wordpress Eric left a note about the problem I had incorporating a latent OpenURL into a Wordpress comment. In a f [...]