[joosters]

While the main concept (Don't change your URIs!) is good, I can't agree at all with their advice on picking names, in particular the 'what to leave out' section. No subject or topic? The justification for this is flimsy at best - 'the meaning of the words might change' So what? People cope with this all the time in other media, e.g. old books. It's not too confusing. What's more confusing is a URI that has all the meaning removed, after all this whole URI discussion is about the human appearance of URIs. Take out the topics and you are just left with dates, numbers and unspecific cruft. If I was designing a company's website, I'm sure as hell going to put the product pages under '/products'.

FWIW, the document's own URI is terrible: 'https://www.w3.org/Provider/Style/URI' - who could have any idea what the page is about from that? And what if the meaning of the word 'Provider' or 'Style' changes in x years from now? :) You could argue that the meaning/usage of 'URI' has already changed, because practically no-one uses that term any more. Everyone knows about URLs, not URIs. Not many people could tell you what the difference was. So the article's URI has already failed by its own rules.

[bad_user]

IMO that's a pretty good URL. For example if you drop it often in conversations, you can remember it, since it's short enough and has no numbers or awkward characters. I would have preferred lower casing and if you try it with lower cased letters, it doesn't work, but other than that ...

No, a URL doesn't necessarily have to give you the title of the article, even if having some related words in it might be good for SEO value. If you paste it in plain text or similar, add a description to it. Here's how:

Cool URIs Don't Change: https://www.w3.org/Provider/Style/URI

There, now the reader will know what's this about.

[SquareWheel]

I don't think being able to remember URIs is particularly useful. In 99% of cases they're clicked on or shared, not recited from memory.

I'd still get far more value out of this:

https://www.w3.org/article/1998/cool-uris-dont-change/

[CaptArmchair]

I think the short gist of it is: naming things is a hard problem.

I think you both stumbled upon a fundamental part of the discussion: the tension between finding a way to identify resources (or concepts, or physical things) in a unique and unambiguous fashion, and affordances provided by natural language that allow human minds to easily associate concepts and labels with the things they refer to.

The merit of UUID's, hashes or any other random string of symbols which falls outside of the domain of existing natural languages, is that doesn't carry any prior meaning until an authority within a bounded context associates that string with a resource by way of accepted convention. In a way, you're constructing a new conceptual reference framework of (a part of) the world.

The downside is that random strings of symbols don't map with widely understood concepts in natural language, making URL's that rely on them utterly incomprehensible unless you dereference them and match your observation of the dereferenced resource with what you know about the world (e.g. "Oh! http://0x5235.org/5aH55d actually points to a review of "Citizen Kane")

By using natural language when you construct a URL, you're inevitably incorporating prior meaning and significance into the URI. The problem is that you then end up with the murkiness of linguistics and semantics, and ends with all kinds of weird word plays if you let your mind roam entirely free about the labels in the URI proper.

For instance, there's the famous painting by René Margritte "The treachery of images" which correctly points out that the image is, in fact, not a pipe: it's a representation of a pipe. [1] By the same token, an alternate URI to this one [2] might read http://collections.lacma.org/ceci-nest-past-une-pipe, which incidentally correct as well: it's not a pipe, it's a URI pointing to a painting that represents a physical object - a pipe - with the phrase "this is not a pipe."

Another example would be that a generic machine doesn't know if http://www.imdb.com/titanic references the movie Titanic or the actualy cruiseship, unless it dereferences the URI, whereas we humans understand that it's the movie because we have a shared understanding that IMDB is a database about movies, not historic cruiseships. Of course, when you build a client that dereferences URI's from IMDB, you basically base your implementation on that assumption: that you're working with information about movies.

Incidentally, if you work with hashes and random strings, such as http://0x5235.org/5aH55d, you're client still has to be founded on a fundamental assumption that you're dereferencing URI's minted by a movie review database. Without context, a generic machine would perceive it as random string of characters which happens to be formatted as a URI, and dereferencing it just gives a random stream of characters that can't possibly be understood.

[1] https://en.wikipedia.org/wiki/The_Treachery_of_Images [2] https://collections.lacma.org/node/239578

[SquareWheel]

Good comment, thanks for sharing.

It's an interesting topic. I agree with you that identifiers can be intended for humans or machines, and there's often different features to optimize for depending. URIs are the strange middle ground where they include pitfalls of having to account for both humans and machines.

In an interesting way, each individual website has to come up with its own system for communication. It may be a simple slug (/my-new-blog/), or it may be an ID system (?post=3). It could be something else completely.

There is some value in offering that creativity, but a system where URIs are derived from content also makes a lot of sense to me. You mentioned a hash which I think is the right idea.

It seems reasonable enough that URIs could take inspiration from other technologies like git, or even (dare I say) blockchain. This leads naturally to built in support for archiving of older versions, as content is diffed between versions.

There's some fun problems to think about like how to optimize the payload for faster connections, then generate reverse diffs for visiting previous versions. Or if browsers should assume you always want the newest version of the page, and automatically fetch that instead.

This solves some problems, and creates many others. Interesting thought experiment anyway.