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

RE: TAG telecon, information resources

From: Bullard, Claude L (Len) <clbullar@ingr.com>
Date: Tue, 29 Jul 2003 09:11:56 -0500
Message-ID: <15725CF6AFE2F34DB8A5B4770B7334EE022DC6D2@hq1.pcmail.ingr.com>
To: "'Graham Klyne'" <gk@ninebynine.org>, www-tag@w3.org, pat hayes <phayes@ihmc.us>

From: Graham Klyne [mailto:gk@ninebynine.org]

>(1) An "information resource" is a one that returns a representation when 
>one does a GET on its URI.

Which means as a distinction, it is observable and testable but transient. 
The results are only valid for the transaction (state returned).

>(2) The exact nature of a resource is unknowable, in the sense that it's 
>not possible to fix a single denotation,  but for an information resource 
>it is circumscribed by understanding the things that GET returns as 
>representations.

Which again means it is transient.

>This, I think, is the basis of shared understanding in 
>today's (pre semantic) Web.  The more different representations there are, 
>the more precisely we might be able to pin down the underlying resource 
>(but never completely).

Nor finally.  The resource owner has a credibility issue with respect 
to reliably returning representations for which previous evaluations yielded

the 'shared' understanding.

As far as I can tell, the term 'information resource' doesn't buy the 
web architecture much except the distinction of negotiation of meaning, 
aka, ontological commitment.

Fielding is right that clients are blind to the meaning, type or class 
of a resource per transaction.  They can only establish a shared
understanding 
that is as reliable as the resource is committed to maintaining it.  So 
the distinction, 'information resource' is yet again, a social distinction. 
It provides a term for describing an operational contract, not a condition 
of the architecture per se.  This is even more particularly true of the 
semantic web.

In simple terms, trust but verify.

len
Received on Tuesday, 29 July 2003 10:12:07 UTC

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