- From: Larry Masinter <LMM@acm.org>
- Date: Tue, 14 Jul 2009 12:46:22 -0700
- To: "'Pat Hayes'" <phayes@ihmc.us>, "'Richard Cyganiak'" <richard@cyganiak.de>
- CC: "'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>
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.) 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. 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. 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. 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. 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. 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. 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. 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. 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. The HTTP specification is *not* about what a "resource" is. It *is* about how to use and implement the HTTP protocol. 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. Regards, Larry -- http://larry.masinter.net
Received on Tuesday, 14 July 2009 19:47:16 UTC