Re: Proposed rewrite for section 3.1

Leo,

> We changed the document a little to reflect that, but you should also 
> NOT focus on section 3.1 for all-truth-that-there is. In fact, the 
> rest of the document gives many tips when to use 303 and when to use 
> 200, and in practice the #-uris are the preferred thing by TimBl.
> Also, you can look into the references to practical implementers that 
> are already using the proposed 303 solution (its been published since 
> 18.6.2005), so we are talking about something that works for some time 
> already.
I was one of the first to support httpRange-14.  I was probably 
responsible to bring this issue (or mess) to the HCLSIG.  And because of 
that, i.e., by practicing it, I realized how little it does but how much 
trouble it incurs. The issue becomes serious when Tim suggested the 
idea, I think proposed by Jonathan and Alan, to infer an assertion from 
HTTP respond code, i.e., 200=IR.  The logic seems right because it would 
allow us to logically detect who has violated the web architecture, 
hence making the self-describing web also self-consistent.  But its 
consequence is, in fact, very profound and serious.  I have argued a few 
month back, it leads to logical paradox, such as if rdf:Resource=IR or not?

The reverse thinking is that: if we cannot invoke the logic of 200=IR, 
then it makes the whole httpRange-14 resolution meaningless and 
useless.  This is why I have reversed my position on the issue, which 
argument is provided at http://dfdf.inesc-id.pt/tr/web-arch.

The #URI wouldn't solve the problem.  In TBL's model, all "/" URI 
identifies web resources and #URI something else.  The information 
resource in that regard can be easily defined as any resource identified 
by a URI without hash.  There should be either no distinction of IR or 
some syntactic definition.  Any other conceptual definition is useless.  
Either way, it makes 303 irrelevant.  This is what I want to prevent 
from you making the similar mistakes to introduce this ambiguous 
concepts to someone-else.    
> I am the editor of the document explaining the proposed http-range-14 
> solution,
> you suggest to rethink this solution  as such.
> This does not affect the document "cool uris for the semantic web" 
> that explains the solution - if TAG finds a new solution, there will 
> be a new editor writing a new document.
Cool URIs are fine - to make all URIs stable, sharable, and linkable. 
Cool URIs are not necessarily logic ally consistent URIs.   So, please 
address httpRange-14 with care because - let me repeat it again - with 
logic, httpRange-14 is a logic paradox; without it, it is useless.  It 
is people's choice and I simply picked the latter because it makes my 
life easier and the web faster.

Regards,

Xiaoshu

Received on Friday, 28 March 2008 12:12:04 UTC