- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Fri, 11 Apr 2008 11:27:09 +0100
- 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? Xiaoshu
Received on Friday, 11 April 2008 10:27:53 UTC