Re: Uniform access to descriptions

Tim Berners-Lee wrote:
>
> On 2008-04 -11, at 19:54, Xiaoshu Wang wrote:
>
>>
>>
>>
>> Michaeljohn Clement wrote:
>>> Hi Xiaoshu,
>>>
>>>
>>>> We agree that there are legacy data, yes?  Let's make its URI x, whose
>>>> owner is Joe.
>>>> Case 1. Joe is lazy.
>>>> Then, no LINK, no Conneg. Is this fair?
>>>> Case 2: Joe is not lazy.
>>>> (a) Joe makes LINK(x)=metadata.
>>>> (b) Joes make Conneg(x)=metadata (can easily GET x Accept
>>>> application/rdf+xml).
>>>>
>>>
>>> (b) would be wrong, because the metadata is not an alternative 
>>> variant of the resource identified by x.
>>>
>> Why wrong? First define metadata?  Say _:x _:b _:y.  Is this 
>> assertion metadata of _:x or _:b or _:y?  You assume it is wrong 
>> because of an arbitrary definition of metadata. In your proposal, any 
>> RDF transformation is the metadata of an HTML, they should be put in 
>> LINK too.
>
> The point is that when conneg is used to return two different 
> representations of a document, with different content types, the use 
> is ONLY to allow negotiation of different formats for the SAME 
> information.
>
> (Sometimes different formats cannot express all the content of the 
> original, so sometimes there is quality degradation. But this should 
> be avoided where possible).
Tim, it sure can work if you tell us (or me) exactly the meaning of the 
SAMEness.  (I am refraining myself to ask you to define information).

Your other suggestion to me is that you should NEVER do content 
negotiation with things that QUITE DIFFERENT. Now, you change the 
wording to you  changed the word to ONLY and SAME without a workable 
definition, I wonder how that can work in practice?

I sincerely wish you not to take my argument as a disrespect to you.  
The fact is that I get to my point is trying to understand why you 
insist to restrict the range of HTTP of slash URI (during the discussion 
of httpRange-14). The reason is: only by that, i.e., to give IR a 
syntactic definition, can you answer what is an IR meaningfully and 
unambiguously.

However, that still won't completely solve the /ambiguity/ problem.  The 
first one is the content-negotiation and the second one is the issue of 
fragment identifiers (I think most people may have not realized this 
problem yet).

To make /slash/ URI to /unambiguous/ denote an IR requires all variants 
(I use variant here instead of format or content type because it is more 
meaningful) to have some kind of mathematical equivalence be defined.  
But I cannot.  Trust me, it is not that I didn't try but I am incapable 
of finding one (obviously due to my limited intelligence).  First, there 
is practical concern. For instance, the full HTML page for ordinary 
browsers vs. the the lossy one for the browser on mobile device.  
Second, I don't believe machine language is capable of fully and 
precisely express human thoughts, hence making any semantical (not 
syntactical) identical transformation from HTML to RDF a moot point.  I 
think you also agree different variants has different degree of degrade. 
In other words, there is always *information loss* during the 
transformation between variants. So, I cannot see how to solve that.

The second issue is what will be the meaning of hash URI even if I 
subscribe to your suggestion.  Once again, content negotiation makes it 
difficult to explain. Using #URI temporarily delayed the argument, but 
it didn't make it to go away.  For instance, if I were asked what 
"http://dfdf.inesc-id.pt/tr/doc/web-arch/img/fig2#rsc" identifies (or 
denotes), I cannot be sure.  There are a few mime-types behind that URI. 
Getting text/html gives me one /document/ fragment and getting 
image/svg+xml gives me another.  But getting image/jpeg gives me none. 
Once again, I couldn't meaningfully and consistently interpret it with 
the current model.

Then, there are two solutions.  One is to drop Conneg.  The second one 
is to take Conneg to a greater role.  I took the latter because I think 
the former will severely limit the web's capability.  The latter 
thinking evolves my new interpretation of the *existing* web 
architecture because a simple readjustment of my understanding, I get a 
consistent model, which is not ambiguous and it solved the above two 
problems at once without requiring any change to the existing web standard.

Honestly, I cannot understand why it has been so hard.  Perhaps, it is 
my poor language skill (I obviously knows that from Pat's articulation 
for my point of view); Or perhaps, it is due to my subconscious 
arrogance (perhaps, and I don't know. But I can be sure that is never my 
intension)? Or is it something else....  

Regards,

Xiaoshu

Received on Sunday, 13 April 2008 09:53:43 UTC