Summary

  • In “Cool URIs don't change”, Tim Berners-Lee argued that an organization's internal changes need not change a document's public address. The W3C naming chronology dates the style-guide essay to December 1998.
  • The essay warned against building employee names, file extensions, software choices, access classes or shifting subjects into lasting URIs. Its operating answer was a server-side mapping from a stable identifier to whatever file or program currently serves it.

A new menu is not a new street

The most tempting explanation for a broken link sounds reasonable in a staff meeting: the website was reorganized. The old menu made no sense; a new team owns the document; perhaps the files moved to a different machine. The 1998 essay answers with an unromantic detail. Web servers can map a URI to a file without making the URI imitate the filesystem. A publisher can arrange the files for today's staff and leave yesterday's public address in place. It can also map the same address to a different program when the machinery changes. The server does the translation. Readers do not have to.

This was a design argument, not a claim that every publisher had already solved it. Berners-Lee listed the excuses he heard for dangling links: a nicer website layout, confusion about which old material was still valid, a file move, a departing maintainer, a change from a CGI script to a binary program. Each excuse points to a real operation. None requires the outside world to adopt the site's internal filing system. A public URI is a promise made at the edge of the organization. The directory tree behind it is an implementation choice.

The distinction mattered because the publisher could not inventory everyone who depended on an old address. Another site might have linked to it. A reader might have bookmarked it or written it in a letter. Berners-Lee's essay states the resulting asymmetry: the server operator knows the change it made; the distant linkers often learn about it only when their path fails. The cost of a redesign is exported to people the redesign team cannot even name.

His example came from the National Science Foundation's online documents. The essay contrasted URLs exposing cgi-bin, a Perl script and a retrieval query with a more durable-looking path containing pubs/1998 and a document identifier. That was a comparison of address design in 1998, not a report that one NSF URL survived to this day. The meaningful difference was which facts a path disclosed. The publication year and document identity could stay true after the office changed its tools. The script name advertised today's implementation as if it were permanent.

The address should survive the staff chart

Berners-Lee's list of volatile ingredients was longer than file paths. An author's name changes when someone else maintains the page. A subject classification changes when an organization redraws its categories. A status such as draft or old changes as work advances. Access can move from a team to members to the public. A file extension can become a lie when the content format changes. A hostname can expose a temporary server role just as a path can expose a temporary script. Put any of those facts in the public identifier, and a routine change becomes a link-maintenance crisis.

The essay's proposed compromise was selective. A document's creation date does not change, so a date can anchor a durable path; a latest address can intentionally name a moving target when that is what readers seek. The choice depends on what the address promises. A dated report and the current issue of a magazine are different things. A publisher that uses one URI for an archive item can keep the item's identity steady while moving the bytes. A publisher that uses a latest URI promises a continuing role rather than fixed content. Neither choice needs to expose the server's disk layout.

Classification was the harder trap. A category seems meaningful to a reader and convenient to a team today. Berners-Lee warned that organizations change names and boundaries, while subjects themselves do not fit neatly into one permanent tree. A URI containing a topic binds the publisher to that classification or forces old links to move when the taxonomy changes. The original essay even describes W3C's own shifting labels, from “MarkUp” toward “HTML.” The point was practical: the web address should not become a referendum on the latest department chart.

The promised cure was another address

One answer to short-lived URLs was to wait for Uniform Resource Names, or URNs, as though a more solemn class of identifier would carry permanence by itself. Berners-Lee was unimpressed. The essay argued that an organization capable of maintaining a persistent URN could already use the same discipline for an HTTP URI. A name still needs an owner, a mapping to the current resource and a commitment to keep that mapping useful. Calling it a name instead of a location does not hire the archivist.

He also admitted an operational weakness in his preferred approach. Ordinary publishing tools did not automatically maintain a database of persistent identifiers, file locations, versions, translations and checksums. Some W3C pages, including the essay itself, were not exemplary. This concession sharpened the argument. Stable identifiers are cheap to type and expensive to keep. A publishing system must be built to let staff move files, change access and hand over responsibility without rewriting the public name. Otherwise the easiest action for each local team will be to issue a new address and let distant readers clean up.

The 2004 W3C Web Architecture Recommendation later put the principle in institutional language. URI persistence is a policy and commitment by the owner; a URI scheme supplies no guarantee on its own. Consistent representations and HTTP redirects can support that commitment. The Recommendation does not turn Berners-Lee's essay into a measurement of how many links failed. It records where responsibility sits when a public identifier is issued.