W3C home > Mailing lists > Public > www-tag@w3.org > May 2005

Re: making progress on httpRange-14 -- yet another suggestion

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Sat, 7 May 2005 23:07:19 +0300
Message-Id: <fb3905b9ee716a279eb0085126b307be@nokia.com>
Cc: W3C TAG <www-tag@w3.org>, Harry Halpin <hhalpin@ibiblio.org>
To: "ext Roy T. Fielding" <fielding@gbiv.com>


On May 7, 2005, at 04:43, ext Roy T. Fielding wrote:

>
>  A computer cannot simply
> perform a GET and assume that what it got back is wholly
> descriptive of the resource ...

>
> ... You cannot discover
> meaning by performing a GET on a URI.  You need to be able to read
> what the provider promises, assume via its context, gather from
> its use by other link authors, or (if you are very lucky) read
> what the owner asserts about the URI in RDF, N3, OWL, etc.
> That is true of any resource.  People who simply perform a GET
> on a resource don't discover its meaning -- they only discover
> a snapshot in time.

Absolutely. Well said, Roy.

I'd love to see these two statements included in some form in
a future version of AWWW!

--

I've long made the argument that the OFWeb does not care one
bit about which resource an http: URI identifies.

The OFWeb *does* care that an http: URI identifies *some* resource,
and that (ideally) one may interact with representations of that 
resource
via that URI, but as to what actual resource is identified, it simply
does not matter to the successful operation and use of the OFWeb.

Likewise, most users of the OFWeb don't care one bit about which
resource an http: identifies. All they care about is that there is a
consistent user experience when interacting with representations via
that URI and that those representations are useful for some purpose.

The SW, on the other hand, does not care whether any http: URI 
identifying
any resource can be used to access representations of that resource.
What the SW cares about are assertions made employing that URI
(triples where that URI occurs) and assertions made about such 
assertions
(relating to provenance, authority, trust, etc.).

The intersection of the OFWeb and the SW is quite simple:

It is the shared set of URIs identifying resources and the (possibly
false or unverifiable) presumption that a given URI identifies the same,
specific resource on both the OFWeb and SW.

The OFWeb provides representations via those URIs.

The SW deals with assertions employing those URIs.

And it need not be any more complicated than that.

If one wants a representation of a resource identified by a given
http: URI, one uses the OFWeb to access a representation.

If one wants knowledge (assertions) pertaining to a resource
identified by a given http: URI, one uses the SW to access
assertions employing that URI (e.g URIQA, SPARQL query portal,
etc.).

And software that operates on both the OFWeb and the SW will
benefit from this simple, clean interface between these two layers,
without having to violate the principle of URI opacity when
reasoning about resources identified by http: URIs (or any other
scheme).

Attempting to constrain the range of http: URIs to identifying only
resources belonging to a specific class of "Information Resources"
(a) only makes the integration of the OFWeb and SW more complex than
it needs to be, (b) does not offer any utility that the URI-agnostic SW
machinery doesn't already provide, and (c) conflicts with the already
established practice of using http: URIs to identify arbitrary 
resources.

In short, trying to constrain the range of http: URIs to a specific
class of resources is simply poor engineering as it introduces 
complexity
without any clear benefit.

I still wait to see clear and motivating examples of how either (a) 
using
a hash URI to identify a non-information resource offers distinct 
benefit
over using a non-hash URI or (b) using a non-hash URI to identify a
non-information resource causes anything to break. To be honest, I'm
not holding my breath...

Cheers,

Patrick
Received on Saturday, 7 May 2005 20:09:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:35 GMT