RE: QA Tips: Make readable URIs

General recommendation:

In the tip don't say

"Despite the fact that URIs are only supposed to be machine
processable, it is yet good to make them behave well when processed
by people."

Rather, say

"In addition to making your URIs suitably machine processable by
following the specifications, making them user-friendly will pay off
in increased readership. Human-processable URIs spread better through
word-of-mouth and plain-text communication, which is a lever you want
to use. Nothing builds trust like a referral from a friend."

Some discussion:

Please see the Architecture Document on URI Opacity:
   http://www.w3.org/TR/webarch/#uri-opacity

for a more up-to-date and less misleading take on this topic than 
Tim's old note:
http://www.w3.org/DesignIssues/Axioms.html#opaque

Machine processing and human comprehension and reproduction of URIs are not
anthetical.  It is both necessary that they be machine processable 
and good that
they be easy for people to process.

It is important that machine processing not treat educated guesses as hard and
fast information that would let these processors make firm decisions that users
can't work around.  But for machine processors to offer the users 
hints based on
reasonable conjectures from the structure of a URI is not a bad thing.

For example, the function in Opera (I believe) that will walk up the 
'path' part
of an http: URI in search of a page giving a better orientation to 
the context is
a positive feature and not counter to the best use of the Web.  It's 
not guaranteed
to work, but it's undo-able using the history list or back button, 
and more often than
not it will get you what you wanted -- backing off to a reasonable 
place to restart
as if an explicit breadcrumb trail had been offered.

The URI path component is so often a usable substitute for a 
breadcrumb trail that
offering this avenue of recovery is a good idea.  Not to be 
discouraged.  Either in
the user agent or in the coining of URIs.

Al

At 5:59 PM +0200 8/18/04, Dominique Hazaël-Massieux wrote:
>Le mer 18/08/2004 à 11:03, Victor Engmark a écrit :
>>  Take the URL http://www.w3.org/QA/2004/08/readable-uri: It tells me that
>>  the protocol is HTTP,
>
>True; the URI scheme is indeed not opaque in a URI.
>
>>   that it is a web page
>
>Not true; the URI may not have been dereferenceable, and even being so,
>it may be something else than what you would call a Web page; it could
>be a picture, a sound file, a CSS style sheet, a piece of RDF, etc.
>
>>   (for somebody not familiar
>>  with the web, w3.org might not look like the same), that W3 is an
>>  organization,
>
>Not true either; although in HTTP URLs, the hostname part is indeed not
>opaque - it asserts something about the server from which you may
>dereference the said URI -, you should not read anything below that
>level; the .org Top Level Domain has many non-organizations domain
>names, and the associated name may mean something very different from
>what you think; look at w3c.com for instance.
>
>>   and that the readable-uri page was published by the QA
>>  group in August 2004.
>
>Not true either; take http://www.w3.org/QA/2005/01/News2004 : I have
>good reasons to believe it was not published in January 2005.
>
>To summarize, when the Tips says that URIs are opaque, it doesn't mean
>one should make sure her URIs are opaque to the rest of the world; it
>simply reminds that somebody should not try to any semantics into a URI;
>there are indeed a few parts one could read into (the URI scheme, in
>some schemes, the authoritative part, ...), but generally speaking, no
>one can assert that http://example.com/APictureOfARedElephant is a
>picture of a red elephant or the 9th Symphony of Bethoveen until she
>dereferences it.
>
>>  AFAIK, URLs are a subset of URIs, with the differences that:
>>  - a URL is not necessarily an identifier, while a URI is, and
>
>A URL is an identifier; logically speaking, if you say that URLs are a
>subset of URIs, you can't say that URIs have properties that URLs don't.
>
>>  - a URL points to data about something, while a URI doesn't have to
>>  point to the information.
>
>The pointers that Olivier gave explains why this distinction is not
>relevant.
>
>>  > [1] http://www.w3.org/TR/uri-clarification/
>  > > [2] http://www.w3.org/DesignIssues/Axioms.html#opaque
>
>>  This seems to me to indicate that URLs like abc://def.ghi.jkl/12345 are
>>  preferable to http://www.w3.org/QA/2004/08/readable-uri.
>
>Nope; again, the tip doesn't suggest that one should make her URIs
>opaque, but that one should not try to interpret someone else URIs.
>
>>  I always thought of it as more of a warning sign: Do not put more
>>  information into URIs than strictly necessary, and leave out all
>>  technical details.
>
>Nope, that's a different (although as important) topic.
>
>Dom
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/ERCIM
>mailto:dom@w3.org
>
>
>Content-Type: application/pgp-signature; name=signature.asc
>Content-Description: Ceci est une partie de message
>	numériquement signée.
>
>Attachment converted: Macintosh HD:signature 82.asc (    /    ) (00061B10)

Received on Thursday, 19 August 2004 19:23:58 UTC