- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 15 Jul 2009 10:32:53 -0500
- To: Larry Masinter <lmm@acm.org>
- Cc: "'Richard Cyganiak'" <richard@cyganiak.de>, "'Roy T. Fielding'" <fielding@gbiv.com>, "'Jonathan Rees'" <jar@creativecommons.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>, <www-tag@w3.org>
On Jul 14, 2009, at 2:46 PM, Larry Masinter wrote: > This conversation is filling my mailbox. Some general > observations: > > (Pat, your arguments are laced with ad hominem, which makes reading > the dialog unpleasant. I don't think Richard is being > silly, intellectually dishonest, bloody arrogant, or any of the > other terms you've used, please refrain.) Sorry if it gave offense, all the above was meant ad dicto, not ad hominem. And Im a Brit, so "bloody" is a friendly form of emphasis. > > It's the nature of standards discussions that people speak > their point of view; doing so isn't arrogant. > > It is the nature of technical specifications that it is frequently > necessary to take normal English words in particular technical > way; it is not intellectually dishonest to do so. Well, let me react to that. (This is an aside from the main topic, but it helps explain motivation and attitude.) True, Richard may have accidentally become the spokesperson here for an entire culture, which I regret if true, and apologize to him for having to bear the brunt of my frustration.) But I do feel that there seems to be what I can only describe as a somewhat arrogant double standard throughout the W3C regarding these issues of technical usage. The W3C documents use a number of words in VERY peculiar ways, ways which (1) do not correspond even remotely to their normal usage and (2) do not conform to the historical usage of these words even in the 'technical' literature out of which the W3C usages have grown, and yet every attempt to ask for clarification of these usages is rebuffed, sometimes angrily or impolitely; and there is nothing even remotely like a glossary available. (Contrast, say, the ISO's almost anal approach to giving definitions of every usage.) My favorite example is "resource", of course (which was first used in this context by Engelbart, who meant it in close to its normal English sense), but "representation" is another, and "identity" (fortunately no longer in wide use) yet another. Seems to me that when your own technical audience has to use your words prefixed with 'awww:' in order to distinguish these deviant meanings from those used in the rest of the world, that there may be a slight issue here. > > It is good practice for technical specifications in standards > groups to say as little as possible in order to meet the > needs of interoperability and the purpose for which the > specification is being written. I strongly disagree. It may be good practice to be deliberately agnostic about technical details, but it is never good practice to be deliberately obscure about the meanings of the words one is using. And you cannot reasonably hold two positions, along the lines of "I am deliberately not going to say what I mean because it does not matter" and "Your interpretation is wrong because that isn't what I meant". Which is exactly what Richard did in this email thread. > > It is not necessary or even possible for a technical specification > to answer questions that may be fundamental for applications > that are outside of its scope. Of course, but this IS in its scope. That is the whole point. > It is common, reasonable, > and traditional for standards specifications to "not answer" > questions because answering the question isn't necessary > for the purpose for which the standard was written. > > It isn't necessary for the proper functioning of the web and > to accomplish interoperability of web clients and servers > to agree on how to use HTTP URIs and the HTTP protocol -- > for that purpose, it isn't necessary to answer the question > of whether a HTTP URI can identify a person. I am not asking it to answer that question. That question is already answered: a URI *can* identify a person. Absolutely no doubt about that. What I am asking for is that the spec RECOGNIZE this and DEAL WITH IT. Richard told me that HTTP "does not care" what the URI identifies, or what counts as a representation of it. I took him at his word and gave him an immediate example of a resource and a representation of that resource, which according to what he had said, I was entirely able to do within the confines of the spec, since it DID NOT CARE about that stuff, and he rejected the example without comment on the grounds that it wasnt to do with computer architecture. Which was exactly my point. If HTTP does not care what a resource is, or what a representation of a resource is, then it should apply to examples like mine. Obviously, it does not: ergo, it DOES CARE what a URI identifies and what a representation is. Then the spec should say this, and say it clearly. Its not enough to hide behind the defense that this is (obviously) just a technical spec in a technical area, and philosophy has nothing to do with that technical topic. That would be fine if URIs could not identify people and books, but they can. It might be OK if http codes didn't imply anything about what URIs denote, but (according to http- range-14) they do. I know y'all don't want to be in this semantic/ philosophical stew, you just want to be technologists. But the fact is, you are in it whether you like it or not. HTTPrange14 put you in it. I didn't make this stew, but I am going to go on yelling as long as y'all refuse to recognize that this stew exists and it is your job to handle it properly, or at least not poison it. The reason why we can't just all assume , in a kind of collegial technophile way, that we are all just talking about networks, is that these very technical usages of words on which you yourself rely to explain the spec have *already* been extended to a wider usage which makes no sense when we are only talking about networks. URIs *can* "identify" people, and other "resources" that cannot possibly have a (n awww:) "representation". > > It may be necessary to answer the question in a technical > specification for the semantic web and in the RDF > specification -- but the answer more likely > belong in those specifications and not in the > IETF HTTP specification. > > It may be necessary for the IETF HTTP specification > be edited in a way that made it clear that it didn't > contain the answer to this question, but I'm not > sure where to draw the line of describing things > it doesn't answer. > > It's easy to imagine a system in which a URI is used > to identify a person for the purpose of that system. For the purpose of the entire Web. It isn't something that can be closeted inside a 'system'. > But I can't see how IETF, W3C, or continued discussion > on any of our mailing lists are going to converge > any time soon on answers to the philosophical questions > that have been with us for millennia. What is it > that "Pat Hayes" identifies, anyway? Can I use > mailto:phayes@ihmc.us as a URI to identify you? > Well, that's a question outside of the "mailto:" > URI spec, I think. Sure. Im not asking you or anyone else to solve age-old problems. But I am asking you to recognize, and say, that HTTP now has some interaction with semantics. Its not a very deep or complex interaction. IMO, it can be entirely contained in the observation that a 200-coded response indicates that the URI denotes (refers to) the resource that it identifies, and a 303 doesn't indicate that. That's all you need to say[[**see below for less**]]: questions of what exactly is the nature of that identified resource, etc., are outside the scope, of course. But you are already assuming that 'the resource identified by the URI' makes sense, right? Because if that is problematic, then the whole of HTTP is problematic. > > Perhaps there needs to be a better way of distinguishing > the statements "this specification does not limit the scope > of applicability" and "this specification applies in all > circumstances". > > If you had some better way of phrasing it so that it would > be clear the former was meant rather than the latter, I > think that would be helpful. > > The fact that something "does matter" -- to you, to the > RDF community, to the W3C, to the world at large -- > does not mean that it is appropriate to "matter" in > the context of the HTTP spec. Well, it does it that thing that matters has been tied to a technical device - a 303 code- that is specified in this spec. > > It is an important design principle for developing > specifications to keep specifications orthogonal: for the purposes > of the HTTP protocol, it does not matter what resources > are exactly. I have never said that it did. I have always consistently said that http-range-14 is about URIs, not about resources. > For the purpose of resource identification, it should > not matter what the protocol is; tying semantic web > interpretation to a particular error code in the HTTP > protocol seems like bad design to me. > > The idea that the HTTP working group should care about the > semantic web and change its specification to meet some > semantic web requirement for use of HTTP URIs in semantic > web applications -- well, that raises several red flags > for me, that we're building specifications that are not > sufficiently orthogonal that things that *shouldn't* matter > are taken as important questions that *must* be answered. I understand about the red flag. But URI issues aren't really just about the semantic web. They are about the whole Web, which is slowly becoming semanticized. URIs convey meanings in all sorts of ways, they aren't purely a transfer protocol addressing mechanism any more. [[**]]If you recall, my interaction on this thread arose from wanting the HTTP spec to simply say that a 303 response can be thrown basically on the server's whim: it needs no "I have no appropriate 200 response to send" justification for the 303. Put another way, the server is not *obliged* to return a 200 response even when it does have a representation available that it *could* respond with. This is purely within the HTTP 'layer', but it is necessary to allow servers to respond with 303s *for semantic reasons* which may (should?) have absolutely nothing to do with the existence of awww:representations. And that is all: I would shut up immediately if that wording were to be used. BUt right now, the wording does have this must-send-200-if- possible constraint in it, which is potentially operationally incompatible with the http-range-14 recommendation. Ironically, it is so precisely because of the orthogonality you want to preserve: the semantics of the URI need have nothing to do with the presence or absence of an awww:representation. It can be determined by other, loftier, matters to do with denotation, whatever that is. I think it would be helpful if the spec could just remark that the reason for this responding-code freedom is because 303 codes have these semantic uses, or that it is generally understood (informative ref httprange14) that 200 codes have semantic implications which might want to be avoided in some cases, or the like, but I also understand your reluctance to include anything in a spec that might come back to bite you. > > The HTTP specification is *not* about what a "resource" is. > It *is* about how to use and implement the HTTP protocol. I don't want it to be about what the resource is, but it does need to at least recognize that the resource might not have ANY possible connection with any computer ever made. It needs to at least show that it understands that not ALL resources are just on the other side of an http interface, even when they are identified by an http URI. > > > There continues to be some confusion in the discussion between > "URI" and "HTTP URI" that I find disturbing and confusing, because > I think sometimes statements about one are attributed to the > other. Not all URIs are HTTP URIs. Please try to be more careful. Point taken. Pat > > Regards, > > Larry > -- > http://larry.masinter.net > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 15 July 2009 15:34:18 UTC