W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: httpRange-14

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 25 Jul 2003 07:30:17 -0400
Message-Id: <200307251130.h6PBUH4F012190@roke.hawke.org>
To: "Roy T. Fielding" <fielding@apache.org>
cc: Norman Walsh <Norman.Walsh@Sun.COM>, www-tag@w3.org

> resource.  The scheme is irrelevant to such assumptions.  The right
> solution is to fix the Semantic Web so that it doesn't throw away
> method semantics, as it does currently by assuming a URI denotes
> what is obtained by a response to GET.

While there is no Semantic Web architecure document, the body of
specifications, applications, and general thought I'm aware of makes
no such assumption.  

In general, there is no guidence given to people to help them figure
out what each URI means, so the risk is that different users (or the
same user at different times) will use a URI in entirely different

For instance, there's no consistent guidance as to whether
means a consortium, a document, or whatever, so reasonable people
might well use it quite inconsistently.   And I think we're agreed
such inconsistent use would be sub-optimal.

> None of this has any impact on the principle that it is unwise to
> use the same URI to identify multiple resources.  That argument
> is and always has been a red herring, and is not solved by
> claiming that "http" means document.

It can greatly help to disambiguate a term if you provide more
information involving it.  If all URIs starting with http: were known
and accepted to identify ResponsePoints, then all the above
misconceptions about .../Consortium would be (thankfully) out the

The fact that "dereference" is used in the httpRange definition (and
elsewhere around here) is a big problem.  The documents talk about
dereference as the retreival operation, but it also parses to many
people as simply asking what something refers to.

       -- sandro
Received on Friday, 25 July 2003 07:30:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC