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?)

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. 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.  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, 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
>
> On Thu, Jun 25, 2009 at 7:36 PM, Xiaoshu Wang<wangxiao@musc.edu> wrote:
>   
>> Eran Hammer-Lahav wrote:
>>     
>>>> -----Original Message-----
>>>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
>>>> Sent: Thursday, June 25, 2009 4:17 PM
>>>>
>>>> Now, given one information, you are proposing three mechanisms to
>>>> specify it.  Isn't it obvious that something is *fundamentally* wrong
>>>> about the proposal?
>>>>
>>>>         
>>> No. That's like saying an HTML document should never repeat any of the
>>> links provided in the HTTP header, etc.
>>>       
>> Of course, it shouldn't.  In fact, no HTTP header should use URI except the
>> Content-type, which unfortunately is not defined in this way.
>>
>>     
>>> The reality is that there isn't any single solution that satisfies all the
>>> use cases we have. After over a year of debating it, this combination of
>>> three methods is the best we have come up with, and it works fine. Is it a
>>> beautiful solution with clean architecture? No. But it is the only solution
>>> we can deploy today and expect people to use.
>>>
>>>       
>> Define your "fineness"?  Making something works does not mean solving the
>> desired problem.  If you know the solution is not clean, you should not that
>> it should not be proposed at this level because it will have long term
>> effects.
>>     
>>> If you read the proposal, it clearly goes through the list of available
>>> methods and states why this approach was chosen.
>>>
>>>       
>> Nope.  Your evaluation on content negotiation is very vague and, in my
>> opinion, partial.
>>
>> Xiaoshu
>>     
>>> EHL
>>>       
>
>

Received on Sunday, 28 June 2009 03:55:51 UTC