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

Re: resource and representation

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 05 Jul 2002 14:02:13 +0300
To: ext Paul Prescod <paul@prescod.net>, Joshua Allen <joshuaa@microsoft.com>, WWW TAG <www-tag@w3.org>
Message-ID: <B94B5765.17E94%patrick.stickler@nokia.com>

On 2002-07-05 10:27, "ext Paul Prescod" <paul@prescod.net> wrote:

> 
> Joshua Allen wrote:
>> 
>> ...
>> 
>> Maybe that is because the discussion has veered off-topic.  There is no
>> question that HTTP returns a representation of a resource.  However,
>> that does not mean that URIs using the http: scheme should be used for
>> things other than web pages.
> 
> There is nothing in HTTP specialized for "web pages" and many people use
> it for things completely unlike Web Pages. Microsoft, in particular, is
> a leader in using it for e.g. email and travel reservations.

Just because someone does something does not make it correct or optimal.
And as I've said many times before, there are things that are done that
work fine for the Web but won't work for the Semantic Web because the
latter has much higher demands for precision of denotation.

>> ... HTTP is just one protocol, with semantics
>> that are useful for a finite set of circumstances.  URIs in practice
>> utilize many schemes besides just http:.  Saying that all resources can
>> or should be identified with http: URIs is completely insane.
> 
> It is indisputably true that all resources CAN be identified with http
> URIs. After all an identifier is just a string and the protocol does not
> effect the binding of identifiers to abstract objects. Whether
> everything "should" be identified with http: URIs is a debate worth
> having. Even without going that far we can observe that HTTP URIs have
> the nice property that it is extremely easy for someone with a web
> server and the appropriate domain name to scalably and globally
> associate metadata in the form of representations with resources.

Whoa, hold on now. You're now saying that metadata describing
a resource is a representation of that resource?! And just how
are we going to differentiate, say, between a representation of
an RDF/XML instance which is bit-for-bit identitical with the
actual resource and another RDF/XML instance which describes the
resource?

It seems the real problem here is the implicit overloading of URIs
by the Web architecture which is far too low a resolution for
Semantic Web agents.

Yes, in theory, the Web architecture provides mechanisms to name each
variant representation separately -- and thus, one could then describe
each variant to express its characteristics and relation to the
actual resource -- but that is seldom used in practice, and
certainly does not appear to be encouraged by the Web architecture.

The problem I see is that in many if not most cases, when the
resource in question is digital, folks expect HTTP to return
a bit-for-bit identitical copy of the resource. Yes, content
negotiation can cause something else to be returned, but in
the case of schemas, invoices, certificates, etc. and many other
kinds of digital resources, we expect to get what we ask for.

The fact that there is no distinction between a bit-for-bit
copy of a digital resource and something else that is not
the resource is the problem. If HTTP wants to return a
representation, even using the very broad interpretation of
representation such that a textual description of the city
of Paris is treated as a representation of Paris, fine, but
it should be consistently clear in the Web architecture
itself, such as in the response codes from an HTTP server,
that what is being returned is *not* a copy of the
resource "at full fidelity" and should be considered as
some other resource that is related in some manner to the
resource denoted by the URI provided to the GET request.

And ideally, the returned resource should *always* be named
if it is not the same resource denoted by the URI of the
GET request.

Only then will semantic web agents be able to deal with
the ambiguity of HTTP GET results.

> urn:
> URIs do not have that nice property and in my mind are thus strictly
> inferior.

No, given DDDS, urn: and http: URIs are no different whatsoever in
this regard. Yes, http: URIs are easier to deploy at the moment,
but they do not differ in the way you suggest, technically.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 5 July 2002 07:02:08 GMT

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