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


> -----Original Message-----
> From: [] 
> On Behalf Of Xiaoshu Wang
> Sent: 28 June 2009 04:55
> To: Jonathan Rees
> Cc:
> 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? 

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.

> 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, 
>, 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.

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

> 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].

[And if you want a framing of the question, it is "What should be deployed on the web at 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."]

> 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]
> > [2]
> > [3]
> > [4]



Received on Monday, 29 June 2009 16:20:07 UTC