Cool URIs don't change
In 1998 Tim Berners Lee wrote an often cited article Cool URIs don't change
- What makes a cool URI?
- A cool URI is one which does not change.
- What sorts of URI change?
- URIs don't change: people change them.
In the article he tackles a number of excuses: "Then why are there so many dangling links in the world?". But the excuse We would like to, but we just don't have the right tools.
Now here is one I can sympathize with. I agree entirely. What you need to do is to have the web server look up a persistent URI in an instant and return the file, wherever your current crazy file system has it stored away at the moment.
Jakob Nielsen's puts emphasis on the importance of keeping links alive in URL as UI
(Alertbox, March 21, 1999):
The URL will continue to be part of the Web user interface for several more years, so a usable site requires persistent URLs that don't change.
Links from other websites are the third-most common way people find sites (after search engines and email recommendations), so build your site to make it easy to attract inbound links:
- Linkrot equals lost business: make sure all URLs live forever and continue to point to relevant pages.
- Do not move pages around but keep them at the same URL: it is very annoying for authors of other sites when their links either stop working or turn into pointers to something different because the original page has been moved and replaced by something new.
And from Nielsen's Fighting Linkrot
(Alertbox, 14 June 1998):
Sometimes Web content becomes truly obsolete. An example would be the advance program and registration form for a conference that has already taken place. In such cases, it makes sense to remove the original page. Even so, the URL should still be kept alive and should be redirected to point to either a follow-up message (e.g., a report from events at the conference) or to a current page that is as close as possible to the original one (e.g., the program for next year's conference).
At other times, it becomes necessary to re-architect a site and impose a new structure. Even then, the rule continues to be: you are not allowed to break any old links. The solution is to set up a set of redirects: a scheme whereby the server tells the browser that the requested page is to be found at a new URL. All decent browsers will automatically take the user to the new URL, and really good browsers will even update their bookmark database to use the new URL in the future if the user had bookmarked the old URL.
Any time one of your old URLs stop working, you are throwing away business. It is like refusing entry to a shop for anybody who is dressed in last year's fashion.
- Keep all old pages on your server forever (unless they are truly misleading and are replaced by an update)
- If moving pages, leave a redirect behind
So there are 2 definitions of 'cool URIs':
- URIs that keep on working, and are kept 'alive' when the original content has moved or has been deleted by either pointing to a meaningful page or by a server redirect
- URI's that have a good 'structure': no
cgi-bin in the name or
/index.html or even
.html as extension. As Tim Berners-Lee puts it: Look for "cgi", "exec" and other give-away "look what software we are using" bits in URIs. Anyone want to commit to using perl cgi scripts all their lives? Nope? Cut out the .pl. Read the server manual on how to do it.
So 'cool URIs' does not say that content cannot change - change is inevitable, especially on a wiki. It is about the strategy how to deal with changed content, or more precise, about the changed location of the content.
Dealing with moved pages is more urgent on public websites than on intranets. But intranets will have to deal with moved files/attachments. Currently TWiki does not have a mechanism to update links to moved attachments (possible follow-up in PluginHandlerForContentMove
- A solution weblogs use agains linkrot are permalinks (see Wikipedia:Permalink): Permalinks typically consist of a string of characters which represent the date and time of posting, and some (system dependent) identifier (which includes a base URL, and often identifies the author, subscriber, or department which initially authored the item). Crucially, if an item is changed, renamed, or moved, its permalink remains unaltered. If an item is deleted altogether, its permalink cannot be reused.
- But we know that Google indexes URIs as well. Google indexes dashes as spaces, creating separate indexable words (
twiki-in-the-news is read as
twiki in the news) , while underscores are interpreted as 'part of a phrase' (
twiki_in_the_news is read as
"twiki in the news"). Google won't make much sense of
TWikiInTheNews. So ideally, a permalink should contain readable words, not a random number.
Possible technical solutions
Policy on TWiki.org:
Currently, TWiki.org is using CoolURIsDontChange in its original sense, e.g. topics should not be renamed. There are exceptions, such as deleting unwanted content, or renaming a topic if it is just a few days old. The TWikiCommunityGroup
can rename/delete content.
So-called "Cool URIs" are discussed in:
Related topics (with a little explanation of how they are related):
- CoolURIsDontChange - the original statement of the problem of dangling links, which really doesn't apply to wikis very well.
- ManageStaleContent - vaguely discussed in how to manage pages that are no longer relevant.
This list in CoolURIs
- RedirectPlugin allows one to produce TWiki topics that automatically redirect to other TWiki topics or URLs. Ooo, shiny!
- TopicRenamedHandler - proposes the idea of a landing page where the user is presented the new link (in case the topic was renamed) from a look-up table
- PluginHandlerForContentMove - proposal for a general alert mechanism if a web, topic or attachments ares renamed
-- Contributors: PeterThoeny
, -- ArthurClemens
The current rename mechanism does of course break URIs. AvoidRenameLosingHistory
suggets one way of avoid this, but still letting people rename.
- 08 Jun 2003
may have some disscussion related to leaving a placeholder for deleted ( and therefore renamed ) topics.
- 21 Apr 2004
"Cool" URIs define a hierarchy or a clean graph structure that allows people to "remember" and use the URLs directly. It also gives a feeling of things being quite simple; complex URLs and too long a URL introduce some kind of uncertainty when dealing with the site.
A plugin that can allow hiearchy on top of flat structure of topics is gong to be very useful for twiki.
- 24 Apr 2004.
Rest of discussion refactored to SearchedURIsCanChange, since that's a more accurate reflection of the discussion.
Refactored bits and pieces from this topic and SearchedURIsCanChange
- 20 May 2006
uses permalinks. Is there a mechanism to use for TWiki?
- 21 May 2006
Bad or misleading URIs should
change, and calling them "cool" doesn't make it so. TWiki manages LinkRot
just fine, so why should twiki.org be rife with sucky or misleading URIs? Or, more positively, ain't it great that we can change topic names and things won't break?
And as long as some are still worshipping at the feet of Berners-Lee and Nielsen:
- There is a crazy notion that pages produced by scripts have to be located in a "cgibin" or "cgi" area.
- :-| make sure that all URLs on your site are less than 78 characters long so that they will not wrap across a line feed
- shorter URLs are better since people often type them manually
- do not use MiXeD case text in URLs
- 13 Jun 2006
PTh: "Policy on TWiki.org: Currently, TWiki.org is using CoolURIsDontChange
in its original sense, e.g. topics should not be renamed. There are exceptions, such as deleting unwanted content, or renaming a topic if it is just a few days old. The TWikiCommunityGroup can rename/delete content."
Of course, an key factor in not renaming a topic is having a "Cool" name to begin with; that is, a well-chosen name that reflects the topic's contents. 404s aren't an issue; neither are the search engines we care about. So the only real issue that I can see regarding renaming poorly named topics are the relatively few pages that are pointed to from the distro directly. In these cases either these topics can't be renamed or there needs to be a redirect to the minty fresh new topic. Other than plugins that don't handle renaming topics, I can't think of a good reason not to rename a topic that either had a bad name to begin with or whose name doesn't reflect the current contents any longer.
- 07 Jul 2006
I do not agree. Think broken search engine links, broken bookmarks, broken links from all TWiki distributions, broken links from blogs, broken links from other websites, ...
- 07 Jul 2006
I mentioned TWiki distros. Anyone who bookmarks to a blog or a wiki -- to any site with highly changeable content -- is a fool, other than to the very few well-known URLs. And search engines fix links nowadays. Or are you suggesting that renaming should be turned off after a few hours? Google hits sites every day, so even a few days is too long. And who knows what pages someone might link to, so topics must live forever under their current name, apparently.
Thank god that blogs have permalinks, so one doesn't have to deal with this nonsense. I'll take "fooblog.com?245" over ReallyMisleadingTopicName any day of the week. And I don't even want to think about what the breadcrumb will look like.
- 07 Jul 2006
One solution is to de-emphasize the topic name, and emphasize the H1 heading (in skin, HTML
- So this calls for separation of topic name (ID) and topic title (human). -- ArthurClemens - 07 Jul 2006
- That would make sense. For example with a TOPICTITLE setting/variable; if not set it is implicitly set to the TOPIC. (or spaced topic name?) -- PeterThoeny - 10 Jul 2006
- The topic name should still reflect the contents, even if it's de-emphasised. The topic name is used for linking. For example, = SearchedURIsCanChange= reflects the contents of the the topic,
SearchedURIsCantChange didn't and therefore needed to be changed.
- 07 Jul 2006