Re: TAG has resolved httpRange-14

Oh dear, I feel the need to comment….and also know that I’m probably going
to cover old ground, but here goes…

Let me start by stating the obvious – I still have a problem with
httpRange-14! In fact, in for - a penny, in for a pound as they say - I
guess that I’m I am also somewhat dissatisfied with Tim’s views on Web
axiomatics and http as a document centric concept. For me, as I stated at
the Boston plenary, there should rightly be multiple web usage dimensions
and, as such, # and / both have a valid place in any ‘master view’ of the

My real problem with # is that is that it enforces architectural
abstraction and makes the possibility of association between ‘things’ of
differing abstraction a non-linear mechanism, if such association needs to
traverse across a ‘document boundary’, adding a great deal of unnecessary
complexity in a number of valid contexts (not just the Sem Web).

# implicitly enforces atomicity at the document level and imposes a
document centric view of the web via http – as I understand has always been
Tim’s architectural intent. Therefore using http as a mechanism to resolve
ambiguity can surely only compound the problem from an architectural
standpoint? This may work well for the current vision of the web, but I
have some concerns about how future proof this approach may or may not be.
Although it is probably a safe bet that text will form the Web’s core
content for some time to come, who could possibly predict what forms of
rich information content will emerge in the future? These could quite
easily transcend the traditional definition of a document and flow over
into much broader and more seamless abstraction schemes. This would promote
a much more holistic view of information aggregation and, in such worlds
the use of # referencing would be to the determent of the web at large?

It’s not that I’m against #, in fact, I also believe that it has great
structural value in specific contexts, like document processing, and am
strongly in favour of it in some places. I also believe that / is next to
structurally useless in some contexts, so we are back to the old argument

For me httpRange14 is not a generalised architecture issue, but one of how
explicitly a usage context needs to be expressed. If a URI contains # then
the producer/author absolutely expects the consumer to accept an
abstraction break at document level, and so deliberately wants to convey a
document centric view of his/her world. 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. Situations where duality of definition and purpose exists are
more troubling, however. In other words, circumstances where sometimes a
resource should be interpreted as a document and others merely as an
aggregate of useful information fragments….

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, say “||” (half hash
:0)), e.g. http://mysite||myinfo. This could 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. It merely denotes that a ‘blob’ of useful things can be found at
a particular address and may be consumed as a document or not – the choice
is up to the target audience. “||” therefore also implies that fragments
will be presented in suitable formats that can support their own
abstraction schemes and ultimately the atomicity of their own individual
parts in a self referential manner – again another obvious statement.

Sorry to ramble…

Kind regards

Phil Tetlow
Senior Consultant
IBM Business Consulting Services
Mobile. (+44) 7740 923328

             "Ralph R. Swick"                                              
             Sent by:                                                   To 
             22/06/2005 13:44          TAG has resolved httpRange-14       

The TAG has announced [1] a resolution of httpRange-14 [2].  I have
updated the post-meeting note in the minutes of our 16 June telecon [3].

   That we provide advice to the community that they may mint
   "http" URIs for any resource provided that they follow this
   simple rule for the sake of removing ambiguity:




I believe this should mean that we can close the following action from
our 7 April telecon [4]:

ACTION: Chairs to discuss the httpRange-14 issue at the coordination level


Received on Monday, 27 June 2005 10:35:34 UTC