- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Tue, 30 Jun 2009 10:12:44 +0000
- To: Xiaoshu Wang <wangxiao@musc.edu>
- CC: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>
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