Re: TB16 Re: Comments on arch doc draft

On 2002-07-03 21:46, "ext Mark Baker" <distobj@acm.org> wrote:

> On Wed, Jul 03, 2002 at 05:03:02PM +0300, Patrick Stickler wrote:
>> Thus, using a mailto: URL to denote a person, or using a web
>> page URL to denote a company, or using a namespace
>> URI to denote both the set of terms and some document
>> describing things related to that set of terms are all errors.
> 
> May I respectfully suggest that folks address this point of Patrick's?
> IMO, this is an *extremely* common misconception, and it appears to
> underly his entire argument.
> 
> Patrick believes that a URI should only identify one thing.  This is
> absolutely true, and I don't think anybody here would disagree.  He
> also believes that the bytes returned in response to a GET are
> necessarily identified by that same URI.  This is not true.

Then I see no point to URIs (if that is not true).

Or I see a growing schism between the Web and Semantic Web.

> For most GETs, it is the case that there are *two* resources being used;
> the one on the HTTP request line (GET <some-uri>), and the one whose
> content is returned as a bytestream representing the state of the other.
> HTTP 1.1 provides the Content-Location header to distinguish between the
> two; its value is the URI of the latter resource.

Well, I've not understood Content-Location to serve that purpose,
though I can see how it could be made to do so. Some clarification,
though, would be necessary regarding its use in this fashion since
the specs clearly speak in terms of 'variants', which are not
entirely different resources, per se, in the same way that a
textual description of Paris is different from the city of Paris
itself.

> If Content-Location is not present, then there is an ambiguity.

Fair enough, but (a) folks in general do not seem to consider it
necessary to use Content-Location to differentiate between e.g.
a person and a web-accessible photo of a person, the latter which
is returned by a GET to the URI denoting the person itself. Thus
the ambiguity is the norm.

And the proposed SHOULD from the TAG that namespace names dereference
to namespace documents does not mention use of Content-Location to
indicate that a different resource from the namespace itself is
being returned. Thus the TAG is itself promoting such ambiguity,
which is severely detrimental to the Semantic Web.

So, while a mechanism seems to exist, it is not used for cases
such as these, but simply for content negotiation of nearly
identitical variant representations of the same resource.

Nice try, but no sale (as presently defined/deployed).

Regards,

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 Thursday, 4 July 2002 04:16:01 UTC