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

Xiashou,

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@musc.edu] 
> Sent: 29 June 2009 18:25
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Jonathan Rees; www-tag@w3.org
> Subject: 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?

I can offer some characteristics and have done so in the past - eg. things that have mass do not/cannot possibly have awww:representations.
Things whose state (and state history) can be serialised as a message can have awww:representations.
Things that are entirely conceptual - eg an RDF property or class fall into a bit of a grey area.

Personnally I could have lived with a resolution to httpRange-14 that allowed descriptive representations for things referenced by slash http URI and left classification of the resource (if required) to some higher level. FWIW, information/non-information resource is a bit coarse grained anyway. 

However, I was also persuaded by Pat's arguments about far-distant galaxies (several light years away) how on earth could they possibly be involved in any http interaction arising from an attempt to access them using a slashed' http URI to refer to them?  Even a physical body somewhat closer?

AIUI the intention of web architecture is that URI are usable to access the things that they are use to name/denote/refer-to (all of which are intented to be aligned). There are things that cannot not possibly be accessed by the web - so the pragmatic thing to do (if you intent to respect that intention of web architecture) is *not* to deploy representations at the http: URI used to name those things.

> Is it 
> O.K. for me to 200 an HTML-representation for myself, which is a person? 

IMO no... it is not ok. 

> 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 think that the TAG has moved beyond it and that the obsession lies elsewhere.

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

Sorry... I can't ground that in anything that I'm aware of.

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

Well... for me the distinction is between things that are:

1) material/physical things
2) abstract/conceptual things 
3) information things (serialisable in a message)

The only one category that gives some pause for thought is the 2nd one, such things certainly admit description, but can they have awww:representation of themselves? (I could go either way).

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

httpRange-14 was asked and resolved in the context of HTTP URI. It has nothing to say about FTP URI.

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

Ah... Well there we have it... See above... a different intention for the architecture.

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

I don't think that you have freedom to do that. The attribution of significance to frag ids is delegated to media-types specifications, doing what you suggest would be a big change. Practically you could do something similar in ? Space eg.

	http://example.net/people/skw?mt=(mine-type)

But again it would be a stretch to get universal adoption... It is little different then from a suffix based convention:

	http://example.net/people/skw		names me, the person,
	http://example.net/people/skw.about	names a document about me (and access to the former are redirected to the latter)

> 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/>
> >   

Stuart
--

Received on Tuesday, 30 June 2009 10:14:05 UTC