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:04:30 UTC