- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 2 Mar 2009 00:26:40 +0100
- To: <eran@hueniverse.com>, <julian.reschke@gmx.de>
- CC: <jar@creativecommons.org>, <connolly@w3.org>, <www-tag@w3.org>
Thank you. Patrick On 2009-03-02 01:19, "ext Eran Hammer-Lahav" <eran@hueniverse.com> wrote: > Yes. I have already committed to doing that and will seek your review before > the new draft is published! > > EHL > >> -----Original Message----- >> From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] >> Sent: Sunday, March 01, 2009 3:21 PM >> To: Eran Hammer-Lahav; julian.reschke@gmx.de >> Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org >> Subject: Re: Q >> >> >> Fair enough. I would ask, at least, that you either correct the >> erroneous >> statements about the shortcomings of URIQA in your draft, or remove >> reference to URIQA entirely from your draft. >> >> Patrick >> >> >> >> On 2009-03-02 01:11, "ext Eran Hammer-Lahav" <eran@hueniverse.com> >> wrote: >> >>> I would really love to dispute almost every statement in this reply, >> but this >>> can go on forever so I'm simply going to thank you for taking the >> time to >>> answer, and let you have the last word, noting clearly that we >> disagree on >>> this topic. >>> >>> :-) >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] >>>> Sent: Sunday, March 01, 2009 3:07 PM >>>> To: Eran Hammer-Lahav; julian.reschke@gmx.de >>>> Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org >>>> Subject: Q >>>> >>>> >>>> >>>> >>>> On 2009-03-01 22:04, "ext Eran Hammer-Lahav" <eran@hueniverse.com> >>>> wrote: >>>> >>>>> I don't need a convincing argument. You do. >>>> >>>> Well, I really am not interested in yet another long drawn out >> debate >>>> of the >>>> same points which have been put forth in the past, since I really >> don't >>>> have >>>> the bandwidth. I was originally motivated to offer some comments >>>> (mostly >>>> corrections) because it seemed from your draft that you (and other >>>> "newcomers") had not understood URIQA very well, and I offer yet >>>> additional >>>> corrections below. >>>> >>>> I do not, however, intend to consume any more of my own bandwidth, >> or >>>> that >>>> of the others on this distribution, as it seems, as before, to >> simply >>>> be a >>>> suboptimal use of my time and energy. >>>> >>>> I will simply continue solving the specific technical challenges >> that >>>> are my >>>> prime responsibility in the best manner possible, and if anyone else >>>> benefits from anything I do, great. If not, cest la vie. >>>> >>>>> >>>>> HTTP 1.1 is widely deployed in web servers, proxies, caches, and >>>> clients. >>>>> URIQA is not. The cost of getting the entire web to support a new >>>> HTTP method >>>>> is huge, especially for a read-access oriented method like MGET >> which >>>> must be >>>>> cacheable and accessible (natively) from the most common web >> platform >>>> (that >>>>> is, JS, Flash, PHP, etc.). >>>> >>>> There are many costs to successfully deploying semantic web >> solutions, >>>> and >>>> most are not tied to server enhancements. It would be en error to >> focus >>>> too >>>> narrowly on just the scope of costs associated with supporting some >>>> additional server functionality, and disregarding the costs and >>>> complexity >>>> of creating, managing, and accessing formal metadata in the most >>>> modular, >>>> efficient, consistent, and scalable manner. >>>> >>>> And your assertion that "the entire web" would need to support such >>>> additional server functionality is invalid. Only those servers which >>>> the >>>> owners wish to support serving of formal descriptions to semantic >> web >>>> agents >>>> would need to be enhanced, and with the exception of <link> >> elements, >>>> the >>>> other linking methods will require as much or more server >> modification >>>> and >>>> enhancement to support a solution than adding a modular self >> contained >>>> URIQA >>>> solution to the environment. >>>> >>>> And BTW, URIQA also alleviates the need for an explicit "host >> metadata" >>>> solution since one can simply execute an MGET on the server root URI >> to >>>> get >>>> such "host metadata" -- Occam's Razor would support the single >> solution >>>> of >>>> URIQA to numerous linking methods and special "host metadata" files. >>>> >>>>> >>>>> As I said before, I like the concept of MGET very much. But I think >>>> it fails >>>>> certain requirements such as: >>>>> >>>>> 1. The ability to assign URI's to metadata. MGET doesn't help me >> when >>>> I want >>>>> to express that B describes A. While B is usually used in >> conjunction >>>> with A, >>>>> it is a discrete resource. >>>> >>>> >>>> Sorry, but that's not correct, and if you look at what is returned >> by >>>> sw.nokia.com, you'll see that every description has a distinct URI >>>> denoting >>>> it (separate from the request URI). >>>> >>>> It's not mandated by the URIQA spec to provide such a distinct URI, >> but >>>> is >>>> recommended. >>>> >>>>> Producing a representation of a descriptor when >>>>> that descriptor doesn't have its own URI seems like a pretty bad >>>> violation of >>>>> web architecture. >>>> >>>> I agree, but as I've noted, this is not a shortcoming of URIQA. >>>> >>>>> >>>>> 2. It fails at multiple levels of meta. If C describes B and B >>>> describes A, >>>>> using MGET, all I have is a URI for A... I have no way of obtaining >>>> C. >>>> >>>> Again, incorrect. Presuming that [A] is the URI denoting A: >>>> >>>> MGET [A] -> description of A (i.e. B), where the response is denoted >> by >>>> [B] >>>> MGET [B] -> description of B (i.e. C), where the response is denoted >> by >>>> [C] >>>> MGET [C] -> description of C, etc. >>>> >>>> Easy (and simple, and efficient, and consistent). >>>> >>>>> >>>>> 3. I strongly disagree it complies with the Equal Access Principle >>>> [1]. >>>> >>>> Well, with all due respect, given the number of misunderstandings >> you >>>> have >>>> clearly had about URIQA, it's hard for me to accept that your >>>> conclusions on >>>> any particular point are valid (they may be, but since I've not seen >>>> sufficient comments from you indicating you actually understand how >>>> URIQA >>>> works and what it offers, I'm unable to give you the benefit of the >>>> doubt). >>>> >>>>> In a >>>>> previous email you listed all the issues in deploying URIQA and the >>>>> workarounds and hacks needed to get it to work. I am unwilling and >>>> unable to >>>>> go on a crusade to get URIQA adopted so that the community I serve >>>> will be >>>>> able to use it. >>>> >>>> I can appreciate that position (though I think it is overstated). >>>> >>>> I think it depends on where you want to ultimately place the burden. >>>> >>>> URIQA simplifies things for creating, managing, and especially >>>> accessing >>>> formal metadata. >>>> >>>> Linking (has the illusion that it) simplifies things for the server >>>> admins/owners (but folks will eventually find out just how much they >>>> will >>>> need to do to get a critical mass of adoption and use, and in the >> end, >>>> things would be a lot easier and cheaper with an approach such as >>>> URIQA). >>>> >>>> Ultimately, the semantic web will succeed or fail based on (a) the >> ease >>>> with >>>> which novel applications can be created and (b) the volume of useful >>>> metadata. >>>> >>>> Whatever solution(s) become standardized (either defacto or >> otherwise) >>>> will >>>> need to effectively address those points. >>>> >>>>> >>>>> If you read my full proposal for Link-based Resource Descriptor >>>> Discovery [2], >>>> >>>> I have. >>>> >>>>> you'd know that none of the 3 methods proposed offer a complete >>>> solution. >>>> >>>> If by "the 3 methods" you refer to the different methods of using >>>> linking to >>>> associate descriptions with resources, then yes, I certainly agree >> that >>>> they >>>> do not offer a complete solution (not even combined). >>>> >>>>> That's why I have 3. Criticizing Links by picking on a single form >> of >>>> link >>>>> (header, element, host-meta patterns) is pointless because the >> first >>>> thing I >>>>> said in my draft is that neither one is complete. >>>> >>>> Well, I didn't pick on any one specifically. I think most of my >>>> comments >>>> apply to all three. >>>> >>>> And I never stated that linking was not a useful technique for >>>> associating >>>> descriptions with resources (and in fact, I explicitly stated the >>>> opposite). >>>> Rather my concern is that such techniques are not simple nor optimal >>>> enough >>>> for a sufficiently broad range of semantic web agents to serve as >> the >>>> primary standardized way that semantic web agents ask web authorites >>>> about >>>> resources denoted by URIs grounded in those domains. I've detailed >>>> several >>>> use cases which give rise to these concerns, so I won't repeat them. >>>> >>>> And I've pointed out those problemmatic use cases many times before, >>>> and >>>> proponents of alternative solutions to URIQA never step up and >> address >>>> them, >>>> so I must conclude none are able to offer a reasonable account. >>>> >>>>> >>>>> I studies URIQA carefully when I performed my analysis and it >> failed >>>> my >>>>> requirements. So far I have not heard anything new to pursued me >>>> otherwise. >>>> >>>> Well, in all fairness, it doesn't appear you studied it well enough, >>>> since >>>> you seem to have gotten most of the key points wrong and therefore >> your >>>> conclusions are based on misunderstanding. I also would have been, >> and >>>> am, >>>> most willing to answer any questions you might have had, or still >> have, >>>> about URIQA, if you truly are seeking to study the problem and all >>>> reasonable solutions objectively. >>>> >>>> Regards, >>>> >>>> Patrick >>>> >>>>> >>>>> EHL >>>>> >>>>> [1] >>>>> http://www.hueniverse.com/hueniverse/2009/02/the-equal-access- >>>> principal.html >>>>> [2] http://tools.ietf.org/html/draft-hammer-discovery >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Patrick.Stickler@nokia.com >> [mailto:Patrick.Stickler@nokia.com] >>>>>> Sent: Tuesday, February 24, 2009 9:24 PM >>>>>> To: Eran Hammer-Lahav; julian.reschke@gmx.de >>>>>> Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org >>>>>> Subject: Re: Uniform access to metadata: XRD use case. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2009-02-24 19:00, "ext Eran Hammer-Lahav" <eran@hueniverse.com> >>>>>> wrote: >>>>>> >>>>>>> I'll separate the two for my next draft and correct this. >>>>>>> >>>>>>> Adding URIQA support in many hosted environments or large >> corporate >>>>>> deployment >>>>>>> isn't simple. It sets a pretty steep threshold on adoption [1]. >>>>>> >>>>>> I've seen such comments before, but have never seen a convincing >>>>>> argument. >>>>>> >>>>>> If you are going to be doing "semantic web stuff" and publishing >>>>>> metadata >>>>>> about resources, then you are going to have to do something more >>>> than >>>>>> just >>>>>> your plain out-of-the-box web server solution, both for serving >> the >>>>>> metadata >>>>>> and for managing/authoring the metadata. >>>>>> >>>>>> A "plug-in" solution like URIQA, which can be integrated into any >>>> web >>>>>> server >>>>>> either by a method redirection proxy or by having the server pass >>>>>> unsupported method requests to it, is trivially easy to add. >>>>>> >>>>>> After all, how hard is it to e.g. add WebDAV to a web site? In >> most >>>>>> cases, >>>>>> pretty trivial. No difference for an approach such as URIQA. >>>>>> >>>>>>> I actually >>>>>>> like the MGET approach a lot, but I can't sell it to 90% of my >> use >>>>>> cases. >>>>>>> Consider me an extreme pragmatists... >>>>>>> >>>>>>> EHL >>>>>>> >>>>>>> [1] >>>>>>> http://www.hueniverse.com/hueniverse/2009/02/the-equal-access- >>>>>> principal.html >>>>>> >>>>>> Well, I read it, but I don't see how URIQA conflicts with your >>>> "equal >>>>>> access >>>>>> principle", in fact, it seems to be quite in tune with it. >>>>>> >>>>>> Patrick >>>>>> >>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Patrick.Stickler@nokia.com >>>> [mailto:Patrick.Stickler@nokia.com] >>>>>>>> Sent: Tuesday, February 24, 2009 8:48 AM >>>>>>>> To: Eran Hammer-Lahav; julian.reschke@gmx.de >>>>>>>> Cc: jar@creativecommons.org; connolly@w3.org; www-tag@w3.org >>>>>>>> Subject: Re: Uniform access to metadata: XRD use case. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2009-02-24 18:18, "ext Eran Hammer-Lahav" >> <eran@hueniverse.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Both of which are included in my analysis [1] for the discovery >>>>>>>> proposal. >>>>>>>> >>>>>>>> A few notes: >>>>>>>> >>>>>>>> The statement "Minimum roundtrips to retrieve the resource >>>>>> descriptor: >>>>>>>> 2" is >>>>>>>> not correct for URIQA. Only one is needed. >>>>>>>> >>>>>>>> URIQA also supports self declaration. The descriptor returned >> can >>>> of >>>>>>>> course >>>>>>>> include statements about the descriptor itself, though typically >>>> the >>>>>>>> descriptor would be a CBD by default, which would not. Still, no >>>>>> reason >>>>>>>> why >>>>>>>> it couldn't. >>>>>>>> >>>>>>>> Not sure why you would consider "Scale and Technology Agnostic" >> a >>>>>>>> negative, >>>>>>>> since in real practice, if you have a server that is going to >>>> offer >>>>>>>> authoritative metadata, you have to enhance the server in some >>>>>> manner >>>>>>>> (e.g. >>>>>>>> to insert links, etc.) so being able to modularly add a >> component >>>>>> which >>>>>>>> doesn't intrude upon the existing core web server functionality, >>>> but >>>>>>>> can >>>>>>>> operate in an auxilliary fashion, satisfying requests for >> metadata >>>>>> in a >>>>>>>> manner not intrinsically tied to how representations are served, >>>> is >>>>>> a >>>>>>>> plus >>>>>>>> in my book. And solutions such as link forces content publishers >>>> to >>>>>>>> mint >>>>>>>> extra URIs to identify the descriptors explicitly, when usually, >>>>>>>> clients >>>>>>>> don't care about the identity of the descriptor, they just want >>>> the >>>>>>>> metadata. So again, "technology agnostic" = "modular" in my >> book, >>>>>> and >>>>>>>> that's >>>>>>>> always a plus. >>>>>>>> >>>>>>>> Perhaps you should split URIQA from PROPFIND since your summary >> of >>>>>>>> PROPFIND >>>>>>>> does not correctly capture its properties, and suggests URIQA is >>>>>>>> essentially >>>>>>>> equivalent, which it clearly is not. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Patrick >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> EHL >>>>>>>>> >>>>>>>>> [1] http://tools.ietf.org/html/draft-hammer-discovery- >>>> 02#appendix- >>>>>> B.2 >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>>>>>>> Sent: Tuesday, February 24, 2009 1:45 AM >>>>>>>>>> To: Patrick.Stickler@nokia.com >>>>>>>>>> Cc: Eran Hammer-Lahav; jar@creativecommons.org; >> connolly@w3.org; >>>>>>>> www- >>>>>>>>>> tag@w3.org >>>>>>>>>> Subject: Re: Uniform access to metadata: XRD use case. >>>>>>>>>> >>>>>>>>>> Patrick.Stickler@nokia.com wrote: >>>>>>>>>>> ... >>>>>>>>>>> Agents which want to deal with authoritative metadata use >>>>>>>>>> MGET/MPUT/etc. >>>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Same with PROPFIND and PROPPATCH, btw. >>>>>>>>>> >>>>>>>>>> BR, Julian >>>>>>> >>>>> >>> >
Received on Sunday, 1 March 2009 23:24:50 UTC