- From: Tim Berners-Lee <timbl@w3.org>
- Date: Tue, 4 Aug 2009 06:24:44 -0400
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Karl Dubost <karl+w3c@la-grange.net>, Pat Hayes <phayes@ihmc.us>, "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <masinter@adobe.com>, Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, W3C TAG <www-tag@w3.org>
- Message-Id: <07E94B69-BAD6-4256-8905-FC942D3AF7DA@w3.org>
On 2009-08 -04, at 00:57, Alan Ruttenberg wrote: > On Mon, Aug 3, 2009 at 9:50 PM, Karl Dubost<karl+w3c@la-grange.net> > wrote: >> >> Le 2 août 2009 à 15:48, Tim Berners-Lee a écrit : >>> >>> On 2009-08 -02, at 07:04, Alan Ruttenberg wrote: >>>> >>>> If you were to go in that direction, I think you ought to consider >>>> adding "Service" as a third category. Thing at the top, with the >>>> children document and service disjoint (not a complete partition, >>>> obviously). >> >> […] >>> >>> Yes, I agree adding Service would help relieve some confusion. I >>> deliberately avoided it in the short history. There is a use in >>> some ways >>> for an ontology which ignores POST services completely, as many >>> systems are >>> just buil;t by making webs. >> >> >> This gives me the feeling of the tree hidding the forest. HTTP >> gives a very >> simple set of words (GET, PUT, POST, DELETE, …) to deal with an >> information >> space. These words are being abused in many ways. (Julia Kristeva, >> poetic >> language and intertextuality?) >> >> Basically we are adding a layer of meaning by fragmenting a generic >> meaning: >> From "Resource" to "Document, Thing and Service". It seems like >> going from >> abstract to more defined material things. This might help >> momentarily but >> will just push the limit to the next iteration of "abuse", the next >> layer of >> fragmentation. > This isn't fragmentation. I am only talking about "Resource", not about other terms, and the problem is simply that it has been used differently in different specs and sometimes ambiguously. > We call this "categorization". It doesn't fragment, it organizes. With > the organization come benefits: predictability, auditability, > understandability. Whereas we have at the beginning "anything is > possible in all cases" (which we know isn't really true - we recognize > brokenness on the web all the time) with this sort of categorization > we can start to articulate why some things work as expected and other > things don't. > Yes. > The web verbs you mention each made sense for particular sorts of > things when they were first thought of. As the web has evolved, the > scope of things to which they can (according to specification) applied > has grown, and with this growth there have become too many cases where > they don't make sense. If a HTTP URI can denote a person, then what is > the verb DELETE supposed to do? Yes. > There are a number of possible paths, as I see it: > > - Let the verbs be used however anyone wants to and have them lose > any distinct meaning. As an example of the sort of direction this > leads us in is one of the ways AWWSW tried to make sense of > Information Resource, by calling it a "200 responder". Circular, and > not very informative. > - Restrict the scope of things HTTP URIs can refer to, paring the > possibilities to those sorts of things conceived of when HTTP was > first created. I get the sense that some in this forum would have it > that way, but the direction the Semantic Web is going says otherwise. > - Start introducing some distinctions into the specifications and > therefore letting there be room again for the verbs to retain some > meaning, albeit by perhaps saying that some of them can't be said > about various sort of things, and that they may mean different things > when applied to different sorts of things. > The latter is what I propose, and really the way we went with HTTP- Range14 and 303. The TAG did it by talking about "Information Resource" as a subclass of "Resource", but I'm just thinking "document" (and service) as a subclass of "thing" will make better matches with the existing cognitive associations for typical engineers. Tim > -Alan > >> Karl Dubost
Received on Tuesday, 4 August 2009 10:25:37 UTC