W3C home > Mailing lists > Public > public-swbp-wg@w3.org > June 2005

Re: TAG has resolved httpRange-14

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>
Message-ID: <OF60DB022F.84110984-ON8025702E.0027A22F-8025702E.002E157F@uk.ibm.com>





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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:43 UTC