The need for “semantic shortening”

If you pay any attention to social networking and internet communication in general, you can hardly have missed the proliferation of “URL shortening” services. From tinyurl, through,,, and many others, they crop up more and more. It’s such a challenge to stick out in the crowd that even a popular shortener is willing to annoy its users by changing how it works.

The usefulness of such services is clear to see. If your messages are limited in size (Twitter, SMS text messages and the like), orif you just want to avoid confusing readers and breaking your text layout, a way of replacing long and rambling URLs with short and sweet ones is very attractive.

But such generic link shorteners have a big problem. A visitor has no way to tell what’s on the other end of a shortened link without clicking on it. Sure, some twitter clients try to be smart by expanding some shortened links when they display the tweet, but that can only ever be a sketchy, partial solution. Who wants to be tied to a particular small set of clients and shorteners?

In a web drowning in malware, trojans and unpleasant content we have learned to check the domain before clicking a link. But with the spread of URL shortening this has become a lot harder. Just one potential misuse of a link-shortener could grab the attention of the excitable media, and lead to widespread mistrust of all link shortening. We need to do something about this problem now.

Possible answers include abandoning URL-shortening altogether, implementing some sort of pre-approval process before a link may be shared, enforcing a standard API to determine the “real” URL and implementing calls to it in every single browser and client, and so on. All of these have significant problems.

For me, though, the stand-out solution is “semantic shortening”. The idea of this is to step away from the idea of a universal shortening tool which can provide a short version of any URL, and instead, provide specific shorteners which only work for certain types of content, or even for certain specific domains. That way, a potential visitor can know something in advance about what the short link points to, before clicking it.

Something like this exists for youtube ( ) While this is useful, it’s just a simple shortening of the existing youtube URLs, and does nothing to prevent safe but annoying links. A true semantic shortener would both provide extra information to let you know a bit more about the target URL, and let you find it on multiple servers.

That’s why I’m working on just such a semantic shortener for books. If you see a link such as or you can be sure not just that the link will take you to information about a book, but that it will take you to information about the book with ISBN 0321344758.

I see a great future for semantic shorteners of this nature, and look forward both to creating more, and to discovering more that other people have made.

New feature – prioritise a local vendor

Early releases had no way of knowing where a reader might be located, and thus had no option but to show all available vendors with equal priority. Today’s release adds some relatively simplistic investigation of the incoming request, to try and determine an appropriate local vendor. All the other vendors are still available, but the “local” vendor gets star treatment and a bit more detail.

A prioritised vendor

I expect this will get more sophisticated as development proceeds. As always. Let me know what you think!

New feature – Use your own affiliate codes

The first release of our social book sharing service was all about creating an ultra-simple way to link to a range of book vendors. It seems to be popular, so it’s time to press on with adding new features.

The first new feature is the ability to supply affiliate codes, if you like to, when you recommend a book. This can be useful if you recommend a lot of books, or just want to get a little bit of cash back if your friends buy a book after following your link.

Adding an affiliate code is also super simple. Just add one or more query parameters after the ISBN or ASIN. Each parameter consists of a short code for the vendor, and your affiliate code. As of this post, we support affiliate codes for the following vendors:

vendor shortname example azus azuk azca azde azfr azit azjp

As new vendors are added, the plan is to support affiliate codes in a similar way, wherever posssible.

Anyone know a quick and easy way to gather (and vote on?) feature suggestions?

I’m looking for a way to gather feature suggestions, thoughts and such from users and potential users about this project. I’m guessing this is a fairly common need, for start-up software in particular, but so far my web searching has not thrown up anything obvious.

I could write something to do it, but I don’t really want to get distracted by that right now. I’d rather press on with getting the main project in a good state to launch.

Any suggestions or experiences with doing this?