Many (most?) organizations’ websites are dynamic creations, assembling pages from databases upon demand. The resulting URLs are long, unintelligible strings, making it difficult for members to give our memorable URLs for particular pages, often breaking in email readers when they exceed one line in length, and generally looking ugly. More troubling, perhaps, are URLs that change over time. The critical page was originally at http://dummy.com/somewhere.htm and is now at http://dummy.com/somewhere_else.html, which means that your clients’ bookmarks will produce 404 error messages. You could, of course, leave the old page in place with an html re-direct on it pointing to the new page, but that’s not likely to happen and is likely to tangle the website more than is practical. (See Ted Tjaden’s piece in Slaw on linkrot for more.)

There are commercial services — typically free to the end user — such as TinyURL and LookLeap! that will shorten that URL for you. For example, the egregious


— the result of a search for 1 King Street West, Toronto, in Mapquest, gets trimmed by these services to



But free services come and go, and one can never be sure that the re-formed URL will be truly persistent. As well TinyURL’s product gives no clue as to the URL’s content, which is another drawback.

OCLC has a Persistent URL service, PURL, that lets any registered user create persistent URLs, with the advantage of the user’s being able to choose what the modifiable portion of the URL should be. (Thus, for example, I resolved the Mapquest URL above to: http://purl.nla.gov.au/NET/king_and_bay. The service allows you to request that the “NETâ€? portion of the URL be replace by your own top-level domain name, and lets you play with partial resolutions and the use of subdomains. As with the commercial services this is not perfect, but it offers the prospect of being around in the near future, at least. As well, of course, it allows the registered user and those permitted by that person to alter the base URL when it changes, so that the end user’s URL will stay valid, effectively creating a re-direct page that lies outside the site and, thus, doesn’t clutter up things or take server space. (For more on the PURL service and the problems it aims at, see their “introduction page.”

A question for Slawyers and readers of Slaw: does your organization make use of PURL or any link resolver? Or do you have a home-grown URL resolver that produces intelligible and persistent URLs?

Comments are closed.