Re: LRDD Update (Resource Descriptor Discovery) and Proposed Changes

Williams, Stuart (HP Labs, Bristol) wrote:
> Xiaoshu, 
>
>   
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
>> On Behalf Of Xiaoshu Wang
>> Sent: 28 June 2009 04:55
>> To: Jonathan Rees
>> Cc: www-tag@w3.org
>> Subject: Re: LRDD Update (Resource Descriptor Discovery) and 
>> Proposed Changes
>>
>> Jonathan Rees wrote:
>>     
>>> [less cc:]
>>>
>>> Tracker, I write this email primarily for you. This whole thread is
>>> about ISSUE-53 [1]. Current LRDD discussion bears on ISSUE-62 [2].
>>>
>>> Xiaoshu, you're essentially pressing the TAG again to make a formal
>>> statement on recommended use of conneg, as Michael Hausenblas did in
>>> February [3]. I'm sorry that this has fallen to the periphery of the
>>> TAG business heap. The best I can do now is to point you to the advice
>>> [4] that we gave to the Cool URIs for the Semweb editors, which agrees
>>> with Eran's reading.
>>>   
>>>       
>> Yes.  I am pressing and I hope TAG can take it seriously.  I am not 
>> pressing TAG to make a recommended use on conneg.  Conneg is there and 
>> people is start using it.  I don't think AJAX community needs to ask TAG 
>> before using conneg.  The mechanism is there, thanks to the well design 
>> of HTTP, we can just use it.  What I am asking TAG to rethink 
>> httpRange-14 because it will let us know how much nonsense that issue-62 
>> as well as LRDD proposal is.  (Sorry for my bluntness, but why waste 
>> time on propose something that you cannot even define?)
>>     
>
> Specifically, what is it that you are asking the TAG to rethink? 
>   
(1) The necessity for the definition of "Information Resource".
(1a) If TAG thinks IR is necessary, please give a concrete definition so 
that every can be used objectively. The current definition is not a 
definition. It is more like a wish but a definition.
(1b) If TAG cannot define IR, then eliminate it.
> The TAGs httpRange-14 resolution and subsequent contributions to the "Cool URIs for the Semantic Web" amounts to saying that:
>
> - fragment-less http URI can be used to refer-to, name... any kind of thing 
>
> - and for things that do not/cannot possibly have awww:representations (and I am such a thing) 
>   please deploy a redirection (303) to a different thing that (if the redirection is to be useful) 
>   has something say about the thing first asked about.
>   
But *please* define the "can", whose capability in what regard? Is it 
O.K. for me to 200 an HTML-representation for myself, which is a person? 
I definitely think that I *can* but I guess you would think so. Then, 
what is the standard of this "can or cannot" list or criteria?

If TAG think that it is O.K. for my kind of "can", then I am fine with 
that because it only says that the concept of "information resource" 
varies from person to person. Else, let me know how to tell IR from 
non-IR because, currently, to be safe (i.e., not being accused of 
violating the web architecture), the only thing that I can do is to 303 
forever.

Note, using hash-URI doesn't get me out of the predicament of "Can I 200 
now? because my hash URI still have to be rooted on some slash URI, 
which IR-ness I must ponder by the httpRange-14.

>> If we know that Information Resource does not make sense, then Generic 
>> Resource does not make sense either because what is the definition of 
>> this genericity?  As I have discussed in the manuscript "Is the Web a 
>> Web of Document or Things?" (Going to be presented in IR-KR 2009, 
>> http://ir-kr.okkam.org/workshop-program/irkr2009-proceedings.pdf), all 
>> these concepts are based on a somewhat "one resource to one 
>> representation" assumption.
>>     
>
> I think I have to cry foul again here. You state repeatedly that this assumption is made in the AWWW or by the TAG and then proceed to argue against it. I can assure you that I know of no-one on the TAG or that contributed to the writing of AWWW that makes that assumption. 
>
> Maybe you are speaking here of an assumption that you make in your work, but I don't think that is the case.
>   
Sure, I sincerely *wish* that I am wrong. But then it is beyond my 
comprehension why TAG is so obsessed with IR/httpRange-14. I remember 
that a few months back TAG was even proposing IETF to 404 back some 
documents. So, suddenly 404 isn't that bad any more, huh? Then, why we 
ask people to make "cool URI"? It really sound ridiculous to me.

It is interesting that in AWWW it says "We define the term “information 
resource” because we observe that it is useful in discussions of Web 
technology and may be useful in constructing specifications for 
facilities built for use on the Web."

I wonder if after so many years of debate. No one has shown even one 
application that has benefited from using the concept of IR. It perhaps 
is what it is -- only useful in *discussion*. Why compound people with 
some concept that we don't even know what it is?
>> It is the same on "the uniform access to metadata".  
>> What is "metadata"?  If you cannot define it, do you 
>> honestly think that a proposal will be of any use?
>>
>> The web is built on three things: URI, Resource, Representation
>>     
>
> AWWW is about those three things (and Interaction).
>   
Of course. But interaction is how the Web is implemented and realized. 
And what a URI denote should have nothing to do with how a message is 
retrieved by a particular protocol. Can I use a ftp-URI to denote a 
person? I sure can, right? And then how do I 303 that? httpRange-14 
breaks the most fundamental principle -- the principle of orthogonal 
specification.

>> There is no fourth or fifth essential concepts.  Metadata,  generic resource, 
>> information resource, whatever they are must be one of the three 
>> entities.  Thus, you have to follow the design pattern of the first 
>> three entities and then consider what we can standardize next for a more 
>> specific problem. 
>>
>> Without solving httpRange-14,
>>     
>
> What (in your view) is not solved? [You may not like the solution, but that is a different matter].
>   
In my view, httpRange-14 solves no problem at all. What it does is to 
create a problem (at least for me). And the created problem is a very 
huge one because the semantics of 200 suddenly becomes murky.
> [And if you want a framing of the question, it is "What should be deployed on the web at http://example.net/people/skw where the intention is that URI is used to name and to refer-to me (the person)? Further the deployment should be such as to avoid the possibility of confusing a reference to me as reference to a document about me."]
>   
You use "http://example.net/people/skw" just as you use your name. 
People needs to realize that what they get is a document retrieved from 
the URI but not what the URI denotes. I have proposed to use 
"http://example.net/people/skw#(mine-type)" to denote the document of a 
particular mine-type retrieved from that document. The treatment is the 
same whether the URI in question contains a fragment or not. Thus, if 
you use "http://example.net/people#skw" to denote you. Then the URI 
"http://example.net/people#(mine-type)skw" would denote a particular 
document-fragment describing you.

Of course, such a #(mine-type) is not absolutely needed, since we can 
always design properties and using b-node, etc to describe it. The 
syntax just makes it more convenient. But no matter what, what a URI 
denotes is always up to the owner of a URI. A client retrieves 
information and judge if s/he should accept it or not. httpRange-14 
basically takes the ownership of URI's meaning away from its owner.

Xiaoshu
>   
>> proposing anything else is like building a 
>> house from top and hope that all those design can consistently converge 
>> to a solid foundation.  I don't think that is the way it works and I 
>> don't think it can work either.
>>
>> Xiaoshu
>>     
>>> Jonathan
>>>
>>> [1] http://www.w3.org/2001/tag/group/track/issues/53
>>> [2] http://www.w3.org/2001/tag/group/track/issues/62
>>> [3] http://lists.w3.org/Archives/Public/www-tag/2009Feb/0074.html
>>> [4] http://www.w3.org/2001/tag/2008/02/28-minutes#item01
>>>       
>
> Stuart
> --
>
> <snip/>
>

Received on Monday, 29 June 2009 17:25:38 UTC