3 ms·

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

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' 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 6y ago
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 https://www.w3.org/Provider/Style/URI There, now the reader will know what's this about.
- SquareWheel 6y ago
  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/ https://www.w3.org/article/1998/cool-uris-dont-change/
  - CaptArmchair 6y ago
    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 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 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 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 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 https://en.wikipedia.org/wiki/The_Treachery_of_Images [2] https://collections.lacma.org/node/239578 https://collections.lacma.org/node/239578

bad_user 6y ago

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 https://www.w3.org/Provider/Style/URI There, now the reader will know what's this about.

SquareWheel 6y ago
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/ https://www.w3.org/article/1998/cool-uris-dont-change/
- CaptArmchair 6y ago
  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 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 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 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 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 https://en.wikipedia.org/wiki/The_Treachery_of_Images [2] https://collections.lacma.org/node/239578 https://collections.lacma.org/node/239578