Comments on: An answer to all (well, some) of your URI questions http://richard.cyganiak.de/blog/2007/03/uri-questions/ A weblog by Richard Cyganiak Wed, 03 Aug 2011 12:16:08 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: my weblog » Best practices des URIs dans le SW. http://richard.cyganiak.de/blog/2007/03/uri-questions/#comment-46722 my weblog » Best practices des URIs dans le SW. Tue, 06 Mar 2007 11:01:48 +0000 http://dowhatimean.net/2007/03/uri-questions#comment-46722 <p>[...] Un article a creuser. Ou, du moins, quelqu’un qui se pose des questions. [...]</p> [...] Un article a creuser. Ou, du moins, quelqu’un qui se pose des questions. [...]

]]> By: Julien Boyreau http://richard.cyganiak.de/blog/2007/03/uri-questions/#comment-46712 Julien Boyreau Tue, 06 Mar 2007 08:52:02 +0000 http://dowhatimean.net/2007/03/uri-questions#comment-46712 <p>Hi Richard, </p> <p>I think the URI Opacity is actually THE problem of REST today and I have seen people on Restwiki trying to challenge this hypothesis. </p> <p>The URL you show are not meaningless at all as you embed the Proper Noun of someone in it, you interprete the domain name as an authority, etc., etc.</p> <p>When you say that it is up to what you got to tell the meaning, this just move the step further as if the Response is an URL, the computer will need something to understand it.</p> <p>REST says that everyting must be an URL, I think that every URL might refer to a thing. As REST makes the transition from the unusable term "Resource" to the meaningful "Noun", I think we should develop mecanisms to translate natural languages Noun in URL i.e a way to say "Richard's last blog article" in a URL in order to be able to PUT at it, GET at it and POST it to categories.</p> <p>If you use "opacity" at the url level, that is machine code, and you will need another programming system at the user level adding at least one layer of redundancy. With proper rules to map main natural language constructs on URL operators (+, -, ., :, @, /, #), URL+HTTP could move the "L" from "Locator" to "Language" and propose an Uniform Language to manipulate symbolic expressions at web scale.</p> <p>Extracting "proper", "common", "plural", "adpositional" or "verbal" constructs from the words we use to build our URLs will restrict the degees of freedom that hackers use when naming their resources, making it easy for HUMAN to bookmark something BUT near impossible for COMPUTER to use it.</p> Hi Richard,

I think the URI Opacity is actually THE problem of REST today and I have seen people on Restwiki trying to challenge this hypothesis.

The URL you show are not meaningless at all as you embed the Proper Noun of someone in it, you interprete the domain name as an authority, etc., etc.

When you say that it is up to what you got to tell the meaning, this just move the step further as if the Response is an URL, the computer will need something to understand it.

REST says that everyting must be an URL, I think that every URL might refer to a thing.
As REST makes the transition from the unusable term “Resource” to the meaningful “Noun”, I think we should develop mecanisms to translate natural languages Noun in URL i.e a way to say “Richard’s last blog article” in a URL in order to be able to PUT at it, GET at it and POST it to categories.

If you use “opacity” at the url level, that is machine code, and you will need another programming system at the user level adding at least one layer of redundancy. With proper rules to map main natural language constructs on URL operators (+, -, ., :, @, /, #), URL+HTTP could move the “L” from “Locator” to “Language” and propose an Uniform Language to manipulate symbolic expressions at web scale.

Extracting “proper”, “common”, “plural”, “adpositional” or “verbal” constructs from the words we use to build our URLs will restrict the degees of freedom that hackers use when naming their resources, making it easy for HUMAN to bookmark something BUT near impossible for COMPUTER to use it.

]]> By: god http://richard.cyganiak.de/blog/2007/03/uri-questions/#comment-46679 god Tue, 06 Mar 2007 04:54:05 +0000 http://dowhatimean.net/2007/03/uri-questions#comment-46679 <ul> <li>Aren’t URNs much more elegant than those brittle HTTP URIs?</li> </ul> <p>No.</p> <pre><code>* Why is everyone yapping about 303 redirects? </code></pre> <p>No one is yapping about this. No one really cares about 30x redirects.</p> <pre><code>* Hash vs. slash? </code></pre> <p>Who cares?</p> <pre><code>* What’s the deal with content negotiation and the Semantic Web? </code></pre> <p>Who cares? Conneg is generally a waste of time, as evidenced by the amazing lack of it's use in ... well ... reality.</p> <pre><code>* Shouldn’t we use blank nodes anyway? </code></pre> <p>No. You should do useful stuff. <del>You know, stuff with utility besides semantic web wankery.</del></p>
  • Aren’t URNs much more elegant than those brittle HTTP URIs?

    • No.

    * Why is everyone yapping about 303 redirects?

    No one is yapping about this. No one really cares about 30x redirects.

    * Hash vs. slash?

    Who cares?

    * What’s the deal with content negotiation and the Semantic Web?

    Who cares? Conneg is generally a waste of time, as evidenced by the amazing lack of it’s use in … well … reality.

    * Shouldn’t we use blank nodes anyway?

    No. You should do useful stuff. You know, stuff with utility besides semantic web wankery.

    ]]>         By: Richard Cyganiak http://richard.cyganiak.de/blog/2007/03/uri-questions/#comment-46616 Richard Cyganiak Mon, 05 Mar 2007 22:38:07 +0000 http://dowhatimean.net/2007/03/uri-questions#comment-46616 <p>@C:</p> <blockquote> <p>the third annoyance, is that you are suggesting using hash uris. imagine what happens when someone requests /data when your app gets even minorly big.. or are you also suggesting changing how every browser on earth works to send the hash and the stuff after it to the server in a GET request?</p> </blockquote> <p>You didn't actually bother to read <a href="http://www.dfki.uni-kl.de/~sauermann/2006/11/cooluris/#choosing">more than the headlines</a>, did you?</p> @C:

    the third annoyance, is that you are suggesting using hash uris. imagine what happens when someone requests /data when your app gets even minorly big.. or are you also suggesting changing how every browser on earth works to send the hash and the stuff after it to the server in a GET request?

    You didn’t actually bother to read more than the headlines, did you?

    ]]>         By: Richard Cyganiak http://richard.cyganiak.de/blog/2007/03/uri-questions/#comment-46615 Richard Cyganiak Mon, 05 Mar 2007 22:34:03 +0000 http://dowhatimean.net/2007/03/uri-questions#comment-46615 <p>@Julien, I'd say that the URI itself (the string of characters) is the wrong place to do the kind of disambiguation you describe. In web architecture, there's the principle of <a href="http://www.w3.org/TR/webarch/#uri-opacity" rel="nofollow">URI opacity</a>, which says you should not use the URI string itself to make guesses about what the URI identifies. You have to actually look at what comes back when you resolve the URI. That's where the disambiguation should happen.</p> <p>@C, I will assume that you come from a strong web and REST background. Then maybe you are quite right to ignore all of this—it doesn't solve any problem that occurs in the traditional Web or REST. That's not what we are talking about, and we didn't bother to include what any web developer should know anyway.</p> <p>We deal with problems that occur when you start making RDF statements about URIs that have been allocated by <em>other people</em>, and then want <em>still other people</em> to be able to understand the statements. In such an environment, the “no semantic hairsplitting” approach quickly hits a brick wall.</p> @Julien, I’d say that the URI itself (the string of characters) is the wrong place to do the kind of disambiguation you describe. In web architecture, there’s the principle of URI opacity, which says you should not use the URI string itself to make guesses about what the URI identifies. You have to actually look at what comes back when you resolve the URI. That’s where the disambiguation should happen.

    @C, I will assume that you come from a strong web and REST background. Then maybe you are quite right to ignore all of this—it doesn’t solve any problem that occurs in the traditional Web or REST. That’s not what we are talking about, and we didn’t bother to include what any web developer should know anyway.

    We deal with problems that occur when you start making RDF statements about URIs that have been allocated by other people, and then want still other people to be able to understand the statements. In such an environment, the “no semantic hairsplitting” approach quickly hits a brick wall.

    ]]>