RE: Q

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:19:54 UTC