W3C home > Mailing lists > Public > www-tag@w3.org > March 2009

RE: Uniform access to metadata: XRD use case.

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Sun, 1 Mar 2009 13:04:36 -0700
To: "Patrick.Stickler@nokia.com" <Patrick.Stickler@nokia.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>
CC: "jar@creativecommons.org" <jar@creativecommons.org>, "connolly@w3.org" <connolly@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723425023C6BAC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
I don't need a convincing argument. You do.

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

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. Producing a representation of a descriptor when that descriptor doesn't have its own URI seems like a pretty bad violation of web architecture.

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.

3. I strongly disagree it complies with the Equal Access Principle [1]. 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.

If you read my full proposal for Link-based Resource Descriptor Discovery [2], you'd know that none of the 3 methods proposed offer a complete solution. 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.

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.

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 20:05:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT