create new tag
, view all tags

Searched (TWiki) URIs Can (and do) Change

There seems to be some misunderstanding (and some FUD) about what is loosely termed "cool URIs". The original discussions about them were before wikis and blogs existed, although some of the points still hold (and, unfortunately, TWiki and at least some other wiki engines violate those points).

As written in CoolURIsDontChange: there are 2 kinds of 'cool URIs': 1) links that keep on working; 2) nicely formatted and human readable URIs.

Nielsen's criteria for a cool URI, circa 1999, are:

  • short URLs.
  • easy-to-type URLs
  • URLs that visualize the site structure
  • URLs that are "hackable" to allow users to move to higher levels of the information architecture by hacking off the end of the URL
  • persistent URLs that don't change
  • Don't use mixed case text in URLs

One must remember that when he wrote that web site content couldn't be changed by users. Wikis and blogs changed that. Wiki engines, including TWiki, are designed to handle topic renaming via scripted repair of internal links. So his last point is doesn't apply.

As to his remaining points:

Criteria for cool URLs

The following applies to almost all wiki engines, not just TWiki.

short URLs

We have a ways to go on that. Having cgi-bin/view in every URI isn't cool. I'm not sure that this can be solved by the engine and most people can't figure out the arcane Apache rewrite module.

easy-to-type URLs

Pretty much the same point

URLs that visualize the site structure

TWiki does this in a literal manner, but not in the way he meant. In traditional websites there are subfolders which add meaning to the URL.

URLs that are "hackable" to allow users to move to higher levels of the information architecture by hacking off the end of the URL

Again, because there isn't a folder-like structure, wikis fail.

Don't use mixed case

Erm, well...


Why Cool URIs Don't Change won't hold on a wiki

On a normal website the URI is part of the metadata of the page. The URI doesn't say anything about the content of the page. When a web page is linked to, a separate link label is needed to make anything human-readable out of it. Compare for instance http://www.wired.com/news/technology/0,1282,66995,00.html which page has the title Mendel's Law May Be Flawed.

On a wiki, the URI is the identifier with which links are created. You name the topic in a text and that createds the link. The link label is not written separately, but is created by the topic URI, and is therefore a semantic device.

When the topic title (and hence the URI) needs to change, it is because of a different insight in the topic's content. The topic text may first deal about something general, and gradually be split up in separate more ideas. A bug report may report something that is perceived one way, while the bug has its origin in another area. At some point it seems better to rename the topic, so that the content of the topic is better recognizable, and as such the changing of the link labels in other topics caused by renaming is something desired.

See TopicRenamedHandler for dealing with this situation.

-- ArthurClemens - 24 Mar 2005

(already mentioned in ManageStaleContent:)

Cool URIs don't change - note that TWiki URIs are not cool at all: cgi-bin in the middle, pages organized by file structure.

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.

Cool URIs don't change - by Tim Berners-Lee (1998)

If we want to have cool URIs we have some work to do.

-- ArthurClemens - 17 Apr 2006

Ok, if we'd wanted cool URIs from the begining we wouldn't have started from here. But we're here now and we want to preserve the URIs that we have. That means that any attempt to move content around on TWiki.org will have make sure people trying to access that content at the old URI will still get to it. This particularly important because of topics like TWikiHistory that have distributed in releases.

So if we decide to mass reorganise Codev for example, we would have to leave behind "stub" topics pointing to the new locations. That's not an ideal solution but if we format them so that they are easy to find again we could run a script at a later date to use RedirectPlugin or a core redirect feature should we introduce one.

-- SamHasler - 18 Apr 2006

Please, comment on the TopicRenamedHandler idea.

-- MartinCleaver - 18 Apr 2006

Even if we don't reduce the number of topics, by moving the content to another web and leaving behind a stub the speed of a full text search is still going to be quicker and give fewer hits.

Martin, thanks. I knew there had been some discussion to add redirect handling to the core. I've bumped TopicRenamedHandler by adding this topic to RelatedTopics. Lets see if it draws any attention and keep it visable.

-- SamHasler - 19 Apr 2006

A good url does not show internals like a cgi-bin directory. So a better url would be twiki.org/documentation/installing-twiki. While the 'internally' used url could be http://twiki.org/cgi-bin/view/2426/2139563542, the user would see in the browser a nicely readable url.

Note that Google interprets urls as well. Dashes are interpreted 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.

continue to point to relevant pages could be understood as not being allowed to change pages. How could that be? I think this should be read as to use redirects to point stale urls to new relevant pages. Because it is impossible to know a site structure and web pages for the rest of eternity: change is natural.

-- ArthurClemens - 18 May 2006

Yes, implementation details such as cgi-bin or foo.php is a bad practice. And good point on twiki_in_the_news.

Please take a moment to browse the http://www.w3.org/ website. They use well designed URLs from the beginning, and you can be sure that they never change them.

-- PeterThoeny - 18 May 2006

Does anybody know why google doesn't expand camelcase in their db (twiki_in_the_news / TWikiInTheNews problem)? Seems like an obvious way for them to improve their service.

-- SteffenPoulsen - 19 May 2006

BTW, this discussion only applies to public sites. There is no way in hell that we're going to convince all the Intranets installations not to change their pages/layouts/titles from time to time just because their users won't be able to bookmark some page. -- RafaelAlvarez - 19 May 2006

And this is an individual choice of site admins. In the end it is a twiki.org "problem".

-- ArthurClemens - 19 May 2006

I think we are looking at this the wrong way. A topic name is just a label, and a label can be used to mark one thing, or a set of things.

Think of a single revision of a topic as an "atom" (a fundamental particle that can't be subdivided). An atom can be uniquely identified using an appropriate string (TWiki uses Web/X?rev=). "Web.X" refers to the latest in the set of revisions of topic X, so it's an ambiguous label for that set of revisions. Similarly "Web" is an ambiguous label for an even larger set of topics and their revisions. However there is nothing but narrow-minded thinking dictating that "Web.X" refers to the head of a set of revisions. It could equally refer to a set of topics.

In use case terms; let's say a web page links to .../bin/view/Web/InstallationGuide. When InstallationGuide was first created it was an unambigous label for the latest revision in a set of revisions that share that name. But now we need to break it up, into CairoInstallationGuide and DakarInstallationGuide. So we create those two topics; and we replace the InstallationGuide topic with a "topic set" (I just invented that).

When a user clicks on a link to .../bin/view/Web/InstallationGuide, they are told of the ambiguity and asked to make a choice. e.g.

InstallationGuide is ambiguous; pick a topic from the following set:
  • DakarInstallationGuide: The following installation instructions are for TWiki-4 and later....
  • CairoInstallationGuide: These instructions will guide you through installing TWiki-3....

-- CrawfordCurrie - 23 May 2006

I am not sure about others, but I am getting more and more confused with so many topics about the same subject. And now with this renamed topic changing the semantics from "can't" to "can" (topic renamed from SearchedURIsCantChange to SearchedURIsCanChange). Kind of ironic, because the URI is no longer cool. Possibly move content back to the original topic and remove this topic?

-- PeterThoeny - 13 Jun 2006

IThe whole point of the "Cool URI" thing was way back before wikis were invented and 404s were rife. And it wasn't like CoolURIs were cool in the "wow, great URL!" sense, only in the un-uncool 404 sense.

The fact is that TWiki topic names can change without a problem, and this is a Good Thing. big grin References get fixed up properly; if someone is daft enough to bookmark a wiki page in the first place, they won't get a 404 but suggested topics; and if one is really desperate to keep the old name, one can do a redirect from the old poorly-named topic to the new better-named topic using the minty-fresh Dakar-friendly RedirectPlugin.

And, uh, search engines fix themselves nowadays.

-- MeredithLesly - 13 Jun 2006

This is great news!

I looked for it in the plugin topic - but I couldn't tell how it solves the problems regarding

  • external links to attachments
  • external links to diffs
  • external links carrying url parameters

.. and the other kind of external links that aren't just straight links to the topic?

Glad we finally have a solution that enables us to go forward on this, keeping our URIs cool - looking forward to trying it out! smile

-- SteffenPoulsen - 13 Jun 2006

External links to attachments are often not a good thing, although that doesn't mean they should be prohibited altogether. Witness the current spamathon, as well as the ever-popular bandwidth theft. If I had to err on one side or the other, I'd prohibit linking to images (and have, in fact, done so on sites I've done) for this reason.

I suppose people could link to diffs, but, um, why? And I do believe that RedirectPlugin does carry the url parameters, since it does a CGIRedirect or whatever it's called.

The fact is that topics can and do get renamed all the time and pretty much nothing breaks. If there are topics that are important to be retained for eternity, they can be locked down to prevent renaming them.

-- MeredithLesly - 13 Jun 2006

I hear these premises for CoolURIs in your discussion: (?)

  1. Some TWiki URIs are / need to be cooler than others
  2. CoolURIs have more senses, at least one is cool and at least one is uncool

For my setups I disagree on both accounts: All URIs need to be cool, and it's the 404 sense that is the cool one of them.

We're back at the SCM / CMS duality as I see it. Perhaps we should try splitting up discussion accordingly, to find common ground in both scenarios instead of trying to look for an agreement where none is.

-- SteffenPoulsen - 14 Jun 2006

I'm not sure where you're getting those premises. TWiki sites don't have 404s (except possibly in the case of linkiing to an attachment), and so there's no issue there to discuss. The only "coolness" issue is whether the topic name is a good one or not.

I'm not sure why there's an argument at all, really, since:

  • Sites that don't want topics renamed can prevent that.
  • Sites that don't want certain specific topics to be renamed can prevent that.

Hopefully my rewriting and pruning of this discussion clarifies things.

Otherwise topics can and are renamed, almost always without problems. The only remaining issue is to help plugins deal with topics being renamed.

-- MeredithLesly - 14 Jun 2006

I agree, let's focus on adding the handler.

-- SteffenPoulsen - 14 Jun 2006

And let's stop worshipping at the feet of "Cool URIs" when, in fact, we don't have them for the most part.

-- MeredithLesly - 07 Jul 2006

OK, on 13 Jun 2006 this topic's name changed from SearchedURIsCantChange to SearchedURIsCanChange. Today, 1.5 month later, Google:SearchedURIsCantChange finds 9 hits on TWiki.org and 6 hits in TWikiIRC. There is nothing I find cool about changing the topic name one month after it was created.

I'd say, lets focus on a human readable name that can be changed.

-- PeterThoeny - 07 Jul 2006

Um, 4 hits (I just looked), none of which are to this page. For some reason when the topic name was changed, the two references (HealingLinkRot and CoolURIsDontChange) didn't get fixed up or someone put in the wrong name. Oddly enough, I get 4 hits on SearchedURIsCanChange as well although, again, none are to this topic. So I'm failing to see the problem. (And, of course, the name was not gratuitously changed but was, instead, changed to reflect the content accurately.)

I don't see anything wrong with having a human readable name. That would be great. I wish I had it while I was building my project. I'm curious, however, how you imagine accomplishing that with the tens of thousands of topics on twiki.org. And being upwards compatible. Etc.

-- MeredithLesly - 08 Jul 2006

Edit | Attach | Watch | Print version | History: r46 < r45 < r44 < r43 < r42 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r46 - 2006-07-08 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.