Re: Subgroup to handle semantics of HTTP etc?

> Mikael Nilsson wrote
>> From: Xiaoshu Wang <wangxiao@musc.edu>
>> I think that semantics should be drawn only from what is asserted in an
>> RDF content, but we should not draw from how the RDF is obtained.  To
>> draw conclusion from a network protocol, such as HTTP, essentially bound
>> URI to its network protocol, which is a very bad idea.
>To me, this amounts to a decoupling of RDF from web architecture,
which is, if I understand thing correctly, exactly opposite to the
purpose of RDF.

I wouldn't go quite that far. I would argue the primary purpose of RDF
is to provide an expressive language for making statements about
'things' (a superset of those 'things' which interact at the web
architecture level).  RDF's intersection with web architecture is but
*one* piece of the value proposition.

> What the server at www.microsoft.org:80 has to say about the URI http://www.microsoft.org/hfy125 is authoritative, according to web architecture, which is not true for *any* other protocol. Therefore any conclusions that can be drawn from that interaction are really interesting.

IMHO, it remains to be seen whether authoritative WRT web architecture
entails authoritative WRT what interpretation you can glean from the
RDF content.  An RDF agent needs a coherent (and consistent) story
about what to make of *both* what the protocol says and what the
payload says about the publishers assertions (the latter being much
more expressive and thus more useful for disambiguation).

>> URI is just a symbol that denotes a thing in the world.
> I truly hope that this is not true, not even for RDF.

Well, this is actually (and emphatically) the case with URIs

>> The form of URI  is just
>> such a design of that, given a URI, who we should ask the question about
>> the URI first without any other knowledge about the URI.
>> I do think that AWWW needs to clarify, but not to say what you can infer
>> but in an opposite way.  I.e., to discourage any "inference" from how a
>> protocol responds to a request.

> I most strongly disagree. I even think that this would contradict the http spec and others, that do support drawing the conclusion that a returned representation represents the denoted resource, etc.

The conclusions supported by these specs were never originally meant
to serve as an inference mechanism, otherwise there would not be any
need to axiomatize these conclusions at this point in time.

> I do think our disagreement does show the need for a TAG statement about the entailments of a http interaction.us

Yes, and I think axiomatizing these entailments will help clarify the
landscape and facilitate better dialog than we have now.

-- Chimezie

Received on Tuesday, 16 October 2007 18:13:31 UTC