- From: Tim Berners-Lee <timbl@w3.org>
- Date: Sun, 6 Apr 2008 22:28:54 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: noah_mendelsohn@us.ibm.com, Pat Hayes <phayes@ihmc.us>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
Others such as Richard have responded well to it, but I worry that new people on this take it at face value. On 2008-04 -03, at 13:02, Jonathan Rees wrote: > > > On Apr 3, 2008, at 10:40 AM, noah_mendelsohn@us.ibm.com wrote: > >> Let's accept what you say above as true. In that case do you believe >> there is there significant value in sticking to the TAG's position on >> httpRange14? You're making the case that even with the existing >> restriction that status code 200 is only for "information >> resources", a >> typical Semantic Web application will still pretty much be >> depending for >> success on the URI owner publishing further information about the >> resource. If that's the case, then why the fuss about 200? ... > > At the risk of drawing out the httpRange-14 debate, which so far I > have tried to avoid... > Well, thanks for trying. :) > I agree with most of what you say, and your question is a perfectly > fine one. My answer is that IMO there is value in httpRange-14, even > if there isn't significant practical value. Excuse me? There was serious practical need to resolve the architecture. Many things were held up, but now can go (and have gone) forward given the resolution. > I think that if we had some accepted way to provide metadata for 200- > responders then the need for httpRange-14 would be reduced, since > there would be another way to say what httpRange-14 wants a 200 > status code to mean. Such an alternative would be superior since > unlike 200 it would not be overloading a message that people are > already using in some cases to mean something different. > People are not, in general, using the message to mean something different. Remember that the web has been around for many years, and has been working, and people have been using URIs. > httpRange-14 is useful in that if a 200 comes from a server that > adheres to it, AND you know that the server adheres to it, then you > learn that the thing is an IR, and therefore not a hen's egg or > doorjamb or protein function. It was only when the semantic web community arrived and wanted to use these URIs in a consistent knowledge representation system -- relatively recently -- that one had to make it clear that when there was a web page about an egg, the URI denoted the page not the egg. For some of us that has been clear for years, but it hadn't be written down clearly enough. > The preconditions are a tall order, Well, the URI is deemed to refer to the web page. This applies to 10^11 web pages already out there. The architecture is such that the URI of a web page denotes it. It is deemed to denote it. It isn't a function of whether the server "adheres" to the idea, just as the ASCII 0x41 denotes 'a' is not a function of whether or not the writer of an ASCII document 'adheres' to the idea. > and the result not terribly informative, and probably not useful to > a computational agent. But it's better than nothing, and might give > guidance to a human trying to understand the URI. There is a huge loss if a system is built which confuses an egg and a page about an egg. This resolution avoids the confusion, for those who might be confused. > The utility of httpRange-14 is significantly reduced as long as not > all minters of URIs for non-IRs adhere to it. I have no idea what > the penetration of httpRange-14 is, but my guess is that it is and > will remain low. It is huge. When you design a global system, you have some global parts of the design which everyone has to agree to. That's the sort of thing the W3C and the ATG are there for. As semantic web systems which actually infer things in a general way about the thing denoted, ad are capable of talking about pages and about eggs, are fairly new those designing them are are generally up date on HTTP-Range-14. As Richard says, systems which break the rule (make statements inconsistent with HTTP-Range-14) mess up all kinds of software, and so they tend to be found and fixed. Perhaps you move in circles less acquainted with the web architecture, and inclined to invent new systems without reference to existing conventions. > The big win of httpRange-14, as I see it, is that it is a positive > affirmation of what was probably the intent of RFC2616, that a 200 > response reflects some inherent connection (maybe even identity, > sometimes) between the information received and the referent of the > name (whatever it is, even if its identity is a secret), and not > just something that a third party has said about the referent. (The > correct thing to say here may be different, but that's OK, any kind > of positive statement is fine by me.) Even if it has no practical > effect, I think it's a bit of pedantry that provokes thought and > helps to influence people to be honest. Wow. Just so that I gauge the way you use terms, would you say that the statement that in the US the voltage between two flat power pins is 110v alternating current is also a bit of pedantry that provokes thought and helps to influence people to be honest? They are both commonly shared agreements which allow things to work as opposed to break. I can't work out whether you are trying to attack HTTP-Range-14 because you don't like it, or really you are confused about how it works and why it is important, or whether you were trolling to stir things up. Tim > My two cents. > Jonathan >
Received on Monday, 7 April 2008 02:29:28 UTC