- From: Phil Tetlow <philip.tetlow@uk.ibm.com>
- Date: Tue, 28 Jun 2005 09:25:13 +0100
- To: "Ralph R. Swick" <swick@w3.org>
- Cc: SWBPD list <public-swbp-wg@w3.org>
Ralph, Ill try to keep this debate brief...At the risk of not understanding all the necessary details, I think that I would just like to briefly add the obvious purely from a Technical Architecture stand point. I hope you dont mind ? *** Many thanks for your comments and, of course, I agree with the practicalities you outline. Nevertheless I guess that I still have a concern with HTTP specifying an abstraction boundary at '#' and the explicitly publication authority it hence provides. Recently I have come to appreciate the work of academics like Stuart Kauffman and the thinking of recognised pioneers like Richard Feynman who (as I understand it) can be seen as promoting models primarily focused on the importance of association and holistics. In such models abstraction is understood as a constraint but is dispensed with at every possible opportunity, letting any 'thing' relate to any other 'thing', regardless of abstraction, so long as a valid reason for association can be found. Such models, for me, relate more closely to an information centric view of the Web - surely the ultimate goal of its architecture? An architecture based around the concept of 'document' is merely a compensating mechanism to aid human understanding based on knowledge reduction through appropriate levels of information aggregation. Agreed, mankind is the ultimate 'customer' here, and information aggregation via documents may be the most familiar, and hence amenable, mechanism available at present, but we should remember that other equally valid aggregation mechanisms exist that could prove stronger from a technical architecture standpoint in the long run. But then I thought this was the whole point behind the Semantic Web and the reason why we were fighting for '/'?....;0) I think the real point we should highlight again to the TAG is that the 'document' concept is only one form of information aggregation, so why make the associated abstractions all powerful and further strongly enforce them via explicit core architecture? Yes, there is a place for such abstraction enforcement, but I would question its placement as a core architectural mechanism. Hence I personally uphold the notion of # as an architectural principle ONLY and the value of a 'half hash' compromise. I think that we should also highlight the obvious notion that information does not necessarily naturally conform to the degrees of freedom imposed by the 'document' concept. From some stand points a holistic view of information needs to be taken across multiple information sources and I think that the web's architecture is still very poor at handling this and will become weakened if the # is enforced so rigorously over HTTP. Alan Rector nicely summed this up recently by referring to the concept of a number of 'connected' (semantic) webs, rather than one (semantic) web. To understand the concept(s) conveyed in such contexts, all contained information must be 'swallowed' by the consumer in one go regardless of what role document containment plays.... Forced information reduction via architectural mechanism can be a dangerous thing and rarely provides a coherent and consistent description from constituent parts through to an accurate picture of the whole. Understanding every single property of both hydrogen and oxygen could not, for example, provide even the slightest insight into the salient properties for water. Nor could an understanding of every single property of water provide even the slightest insight into the ultimate behaviour of a tidal wave. Kind Regards Phil Tetlow Senior Consultant (Technical Architect) IBM Business Consulting Services Mobile. (+44) 7740 923328 "Ralph R. Swick" <swick@w3.org> To 27/06/2005 17:57 Phil Tetlow/UK/IBM@IBMGB cc SWBPD list <public-swbp-wg@w3.org> Subject Re: TAG has resolved httpRange-14 At 11:35 AM 6/27/2005 +0100, Phil Tetlow wrote: >... If a URI contains # then >the producer/author absolutely expects the consumer to accept an >abstraction break at document level, And what's more, the HTTP specification says that there's abstraction boundary at '#' -- the document content type (aka MIME type) is the authority for instructing the consumer about the interpretation of the fragment identification (or sometimes known as "view"). >and so deliberately wants to convey a >document centric view of his/her world. I don't follow this particular point. For "information resources" of type application/rdf+xml, we SemWeb folk are free to specify [1] that fragment ids are one way of crossing the abstraction boundary from documents to arbitrary things, concepts, RDF Resources. But I don't follow how that implies that RDF has a "document centric" view of a world. [1] http://www.ietf.org/rfc/rfc3870.txt > If its slashes all the way then the >concept of document has deliberately been dispensed with, whether >information if dished up in the form of a document or not. But this should >be obvious. Not obvious to me at all. Indeed quite the opposite; the naive view feels more likely to me to be that slashes represent directories (or "folders" for the more-recently-innoculated) thus reinforcing a document orientation. But perhaps you mean to point out the trailing slash case, which would seem to more likely denote the contents of a folder (of documents), even to those who've never administered an apache server. > Situations where duality of definition and purpose exists are >more troubling ... where sometimes a >resource should be interpreted as a document and others merely as an >aggregate of useful information fragments. I think there's broader agreement on the inadvisability of multiple interpretations that you seem to feel. The TAG's current resolution appears to find a navigable path between a URI that names an information resource and a URI that does not -- but that never the less is still useful _in the deployed Web_ to return to the consumer some useful information. >So, if for no other reason than mediation and in the spirit of crazy ideas, >how about the notion of using a third URI constructor [to] explicitly denote the >situation outlined above, where the producer/author deliberately does not >need/want the consumer to take a particular view on the resource being >published. I'm somewhat uncomfortable with the higher level of abstraction to which you're attempting to take us here. I think it is important that some part of an author's intent be manifest -- and that the consumer thereby be able to hold an author/publisher accountable for it. However, I am _very_ concerned about the practical deployment issues of your abstraction in the Web. It seems to me that where there are architecturally acceptable solutions that work with today's deployed Web we should give those solutions much higher preference. -Ralph
Received on Tuesday, 28 June 2005 08:25:21 UTC