W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: Uniform access to descriptions

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Fri, 11 Apr 2008 11:27:09 +0100
Message-ID: <47FF3CFD.40608@musc.edu>
To: noah_mendelsohn@us.ibm.com
CC: Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, Pat Hayes <phayes@ihmc.us>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org WG" <www-tag@w3.org>

noah_mendelsohn@us.ibm.com wrote:
> Xiaoshu Wang writes:
>> If HTTP(x)=200, x=IR
>> If HTTP(x)=303, x=?w
> Pat Hayes writes:
>> Actually no, it results from the fact that the Web has 
>> randomness in it. And such scruffiness is inherent in any 
>> artifact this big, and nothing can be done about it, so we need
>> to work with it rather than complain about it.
> I think Pat's point is very important.  If the criterion for our semantic 
> Web triple is literally: "If HTTP(x)=200, x=IR", then we can probably only 
> apply it in cases where we either own the resources ourselves, or have 
> private communication with the owner.  Even if the specification of IR 
> were crystal clear, there is always the chance that the owner of some 
> random resource didn't understand it, or didn't care.  In a similar vein, 
> we might be tempted to make a statement along the lines of:
>         If method=GET, interaction is SAFE
> I think the parallel is pretty good.  Being SAFE is a concept that is 
> explained reasonably well, but it's easy enough to find resource owners 
> that put out Web interfaces along the lines of "Click here (I.e. do a GET) 
> to confirm your magazine subscription."   So, if we're looking for the 
> rigor that Xiaoshu seeks, we'll likely not be able to make this statement 
> either.
> So, I think the best we can do is to make a statement that says:
>         If HTTP(x)=200 then either
>        (a) x=IR
>          - or -
>        (b) the resource has been
>            deployed incorrectly
>          - or -
>        (c) x falls into an edge
>            case about which users
>            of the Web disagree
> As a practical matter, that may well be enough to support tools like the 
> tabulator assuming (a), which is what we want.  (b) and (c) are there to 
> make sure that, as Xaioshu desires, one badly deployed resource doesn't 
> break the consistency of the entire semweb graph.  Tools that require 
> absolute consistency must realize that the precise semantic of 200 >as 
> deployed in practice< includes (b) & (c). Of course, it would be nice if 
> the Web were a less messy place, but I think we need to account for the 
> reality in defining the semantics of our triples.
I think my point of view is not about rigorous of the logic but the 
separation of the logic.  HTTP protocol is a transportation protocol.  
Hence, the semantics of HTTP should be ALL about delivering message and 
its parsing and it should have nothing to do with judging its content.  
I didn't propose a rigorous logic.  My view is just the opposite - that 
is completely relaxed because my position is (2) but not (1x).  It is 
the httpRange-14 that tries to make it rigorous and I tried to argue 
that it won't work.

The implied message of the httpRange-14 and the definition of IR is 
trying to find a way to say "message"="resource".  But they are - in 
fact - two different entities.  One is on the client side and the other 
one on the server side.  No matter how close or similar they are (in 
terms of byte-copy), there are at last two DIFFERENT entities.  Content 
negotiation makes all proposed solution for "message=resource" to break 
down regardless how you want to limit the definition of IR.

The delivery of a message is SAFE, therefore, doesn't imply the content 
of message is safe (whatever it means).  They are two different issues.  
We should understand the nature of a  resource from what its content is 
telling us but NOT from *how* its content is delivered. Isn't this the 
founding principle of the web - the principle of orthogonal specification? 

Received on Friday, 11 April 2008 10:27:53 UTC

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