User-Centred Linking

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?

After all hypertext originally offered the promise of multiple destinations for a single given link. Bob DuCharme has recently demonstrated how this can be achieved using XSLT and Javascript. However this seems most applicable when the author knows of a variety of useful end-points for a link and can directly author them into the document. It’s unlikely that anyone to take the trouble to deal will all possible end-points for a book link however. It’s also very time-sensitive: even if I do include links to as many book sites as I can, if an “Amazon-killer” site appeared (Google Books?) then my readers won’t be able to get to it without some extra work on their part.
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.
Thirdly we can dynamically generate links at the point when a page is delivered, using a templating engine or even just Javascript.
So all we need to do is provide in our blogs/sites a way to “Manage My Endpoints” which simply lists a menu of link types and some entry fields for the target URL. These URLs would include wild cards for where the identifier needs to be inserted. This data can be stored in a cookie. Then I can include some standard Javascript in the site templates, and a suitable onClick handler to my links, that will use the resource identifier plus the user preference to build the real link. This seems nicely decentralised, and very RESTful.
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.