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 Wednesday, 25 February 2009 05:22:32 UTC