There’s usually more than one way to get something on the net. There are dozens of online bookstores, search engines, new sites, document repositories, etc, etc. And we all have different preferences. Even for sites like Google and Amazon there is room for choice, e.g. different Google mirrors or regional Amazon sites.
Yet when we construct links we are always linking to a single one of those resources. In some cases that is because of an explicit recommendation. We know that one site is cheaper, has better information/context, etc. In others its simply because that’s the first place we looked at in order to be able to link a reader to the resource we’re talking about.
But why not give the user more choice, and let them decide the destination?
Of course in a wider sense the “right” way to do this is not to use URLs at all. Instead we introduce URNs (Uniform Resource Names) and simply name the resource. Its up to the browser to find a URN resolver that will let them locate the resource. This is viable but I don’t see a great deal of activity here, although the DOI is catching on in publishing circles.
So I’ve been musing about other ways to achieve the same ends. John Udell has demonstrated one alternative in the Library Lookup project: provide bookmarklets that scrape the URL or the page for an identifier then build a link to an alternate preferred site. In that instance directing users to an OPAC rather than Amazon.
Another option is to not link to the actual resource at all, but instead direct users to a resolver service that forwards them on according to a preference stored in a cookie. I’ve written about this previously in my “Make A Book Link” suggestion. You can think of it as a pseudo-URN in a way. I recently came across Link Baton which seems to achieve this in a fairly general way.
Unfortunately its not a very de-centralised solution: the resolver is a point of failure. One way to get around this would be for browsers to support additional preferences that allow the user to specify a given resolver for a particular type of link. This would allow users to route around outages by changing their preferences either permanently or temporarily. But again this doesn’t seem like a feasible solution as its unlikely that browser vendors would support it.
I’ve started to think that a viable solution might be a hybrid approach:
Firstly exploit the fact that different sites, while having their own link structures generally include unique identifiers for content (e.g. ISSN, ISBN, etc) that allows us to parameterise the link creation. This is essentially what Udell is relying on.
Secondly exploit the fact that we allow a user to store preferences in their browser, in a reasonably extensible way using cookies. This is what Link Baton is relying on.
Of course it places some work on the shoulders of the site owner, but much of the work seems like boiler plate code/pages which can be easily introduced into any blogging tool. And it does mean that you have to reset preferences for ever site you read, but I’m sure there are ways around this, and besides in some cases you may not need to alter the preference: the author of that site may share your choice in end-point.
On a related note I’ve also been wondering about the usefulness of standardising query strings. The library community are already doing this with OpenURL which basically defines how to pack bibliographic metadata into a query string. This means you can construct a URL to an OpenURL compliant service just by knowing the base URL of that service.
I wonder whether this could be generalised to other types of linking? E.g. having search engines provide standard syntaxes for adding keywords, page sizes, sort orders, etc.
One thought on “User-Centred Linking”
Saw your post to xml-dev a few weeks ago on Openly Informatics and their patent claims. Re: LinkBaton – This is pretty much a direct copy of Herbert van de Sompel’s SFX which is precisely the type of distributed resolver service you are talking about (LinkBaton was just a centralized version of SFX so that libraries wouldn’t have to implement and maintain their own resolver). SFX was subsequently acquired by Ex Libris and is incorporated into their library products. I think the specification is still open though and anyone can implement an SFX resolver. Herbert is of course also the driving force behind OpenURL. More info on SFX can be found in his three articles in D-Lib magazine:
Publishers can support SFX services for their end users fairly trivially and the OpenURL I think grew out of the effort to have the SFX URL contain as much information as possible for the resolver.
Comments are closed.