W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

Re: referendum on httpRange-14 (was RE: "information resource")

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 25 Oct 2004 11:33:13 -0400
Message-Id: <2F29A48A-269B-11D9-A2FE-000A9580D8C0@w3.org>
Cc: <www-tag@w3.org>, <sandro@w3.org>, <Norman.Walsh@Sun.COM>
To: <Patrick.Stickler@nokia.com>


On Oct 20, 2004, at 7:42, <Patrick.Stickler@nokia.com> wrote:

>> -----Original Message-----
>> From: ext Tim Berners-Lee [mailto:timbl@w3.org]
>> Sent: 20 October, 2004 04:19
>>
>> On Oct 19, 2004, at 4:09, <Patrick.Stickler@nokia.com> wrote:
>>> [...]
>>> Also, using a particular URI to identify the *picture* of a dog
>>> does *not* preclude someone using some *other* URI to identify the
>>> *actual* dog and to publish various representations of that dog via
>>> the URI of the actual dog itself; and someone bookmarking the
>>> URI of the *actual* dog should derive just as much benefit
>>> from someone bookmarking the URI of the *picture* of the dog,
>>> even if the representations published via either URI differ
>>> (as one would expect, since they identify different things).
>>
>> No, they would *not* gain as much benefit.
>> They would, under this different design, not have any expectation of
>> the same information being conveyed to (b) as was conveyed to (a).
>> What would happen when (b) dereferences the bookmark? Who knows
>> what he will get?  Something which is *about* the dog. Could be
>> anything.  That way the web doesn't work.
>
> I strongly disagree. And your statements directly contradict AWWW.

Precicsely.
The hypothesis you proposed ( using a particular URI to identify the 
*picture* of a dog
does *not* preclude someone using some *other* URI to identify the
*actual* dog) led to the conclusion (that the representations would
not carry consistent content) you strongly disagree with.
The hypothesis fails.


> It is a best practice that there be some degree of consistency
> in the representations provided via a given URI.

Absolutely.

> That applies *both* when a URI identifies a picture of
> a dog *and* when a URI identifies the dog itself.
>
> *All* URIs which offer consistent, predictable representations will be
> *equally* beneficial to users, no matter what they identify.

Now here seems to be the crunch.
The web architecture relies, we agree I think, on this consistency
or predictability of representations of a given URI.

The use of the URI in the web is precisely that it is associated
with that class of representations which could be returned for it.

Because the "class of representations which could be returned"
is a rather clumsy notion, we define a conceptual thing
which is related to any valid representation associated with the URI,
and as the essential property of the class is a similarity in
information content, we call the thing an Information Resource.

So a URI is a string whose sole use in the web architecture
is to denote that information resource.

Now if you say in the semantic web architecture that the same  will 
identify
a dog, you have a conflict.


>
>> The current web relies on people getting the same information from
>> reuse of the same URI.
>
> I agree. And there is a best practice to reinforce and promote this.
>
> And nothing pertaining to the practice that I and others employ, by
> using http: URIs to identify non-information resources, in any way
> conflicts with that.

Well, it does if the semantic web can talk about the web, as the 
semantic web
can't be ambiguous about what an identifier identifies in the way that
one can in english.

I want my agent to be able to access a web page, and then use the URI
to refer to the information resource without having to go and find some 
RDF
somewhere to tell it whether in fact it would be mistaken.

I want to be able to model lots and lots of uses of URIs in existing
technology in RDF. This means importing them wholesale,
it needs the ability to use a URI as a URI for the web page without 
asking
anyone else.

Tim BL
Received on Monday, 25 October 2004 15:33:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:01 UTC