- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Thu, 20 Apr 2006 17:40:20 -0400
- To: "Pat Hayes" <phayes@ihmc.us>
- Cc: <public-swbp-wg@w3.org>, "Guus Schreiber" <guus@few.vu.nl>, "Steve Pepper" <pepper@ontopia.net>, "Mark van Assem" <mark@cs.vu.nl>, "Ralph R. Swick" <swick@w3.org>
Pat, It sounds like you are mainly disagreeing with the TAG's guidance. I think it's important that the working group conform to the TAG's guidance, even if that guidance isn't entirely baked. However, I applaud your efforts to help straighten out our thinking around these issues. More below. > From: Pat Hayes > > It might be best to start with a definition of what you consider an > information resource to be. Since the TAG do not define this critical > term, yet base important engineering decisions on it, any > authoritative exposition would be of immense value. My current > understanding is that an information resource is some thing that can > be transmitted over a network by a transfer protocol. On this > understanding, one could argue that a word was an information > resource. Definitely not. That would be a "representation", not an "information resource". The information resource is the *source* of "representations" that can be transmitted over a network. I have also been struggling with trying to guess what the TAG meant an "information resource" to be, or more notably, what the TAG meant it to exclude. FWIW, here is my proposed working definition of the day: An information resource is all and only a logical HTTP endpoint that is intended to serve representations with a 2xx response code. Note that: - If something is never intended to return a 2xx response code then it is not an information resource. - It is "logical", not physical. - It is "all and only" because it does NOT include anything else that might be attached to that information resource. By this definition, a resource that is an "information resource" cannot also be any other kind of resource. This means, for example, that an information resource cannot also be a person or Dan's car. However, it could be a part of Dan's car, or it could be associated with a person. > . . . > >To be specific, [8] tells us that the URIs we choose for each of the > >WordNet synsets, word senses, and words MUST be served with > >a 303 See Other response. > > [8] does not use the word MUST, and again, I suggest that it would be > a serious, indeed disastrous, error, to interpret it this strongly. I think you're quibbling here. The difference between RFC2119 terms "SHOULD" and "MUST" is that "SHOULD" permits exceptions to a general rule in particular circumstances, whereas "MUST" does not. But you seem to be arguing against the general rule -- not for an exception. > The 303-indirect mechanism suggested by [8] is ill-thought-out (it is > based, erroneously, on a distinction between types of resource, > rather than on the a distinction between types of relationship > between names and resources), I would very much like to understand better what you mean by "types of relationship between names and resources". Can you explain further? > critically underspecified (no > definition is given of "information resource") pointless (it does not > in fact do any disambiguation) and potentially harmful (it imposes a > needless implementation burden on semantic applications, to > absolutely no useful purpose), and should not be followed by any > responsible semantic web practitioner. [8] is a BAD DECISION, > possibly the worst bad decision ever made by a standards body since > the 8-track tape. It is based on a failure to grasp the basic issues, > it achieves nothing, and it will seriously hamper the development of > the semantic web. The only responsible attitude to take to this > decision is to ignore it. Even if the httpRange-14 decision is wrong-headed (and personally I am not yet convinced either way, though I *am* convinced that it is problematic as is, and I have very much appreciated reading your perspective) I don't see a huge harm in causing some extra network accesses while we further straighten out these issues. (And the extra network accesses can even be optimized away if URIs are minted with a 303-forwarding prefix such as "http://thing-described-by.org?" , as described in http://lists.w3.org/Archives/Public/public-swbp-wg/2005Aug/0057 .) > . . . > > [8] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html > . . . . David Booth
Received on Thursday, 20 April 2006 21:43:34 UTC