Re: Server and client burden for URIQA vs. Link:

On 2009-02-25 20:11, "ext Jonathan Rees" <jar@creativecommons.org> wrote:


Hi Jonathan,


> (spun off from  Subject:        Re: Uniform access to metadata: XRD use case.)
>
> On Feb 25, 2009, at 11:01 AM, <Patrick.Stickler@nokia.com>
> <Patrick.Stickler@nokia.com
>> wrote:
>
>> The arguments that a linking approach imposes less implementational
>> burden
>> or disruption to web sites or content publishers than approaches
>> such as
>> URIQA do not bear scrutiny.
>
> The server burden is an empirical question and I'd love it if someone
> did some research, since MGET is superior in many ways. I take your
> word for it that the Apache configuration required for MGET is as easy
> as for Link:, but I have no idea how the comparison would go on other
> platforms.

>From what I've seen to date (and admittedly, I haven't looked at any
particular web server/platform for awhile, being busy with other things)
adding URIQA support to a web server specifically depends on whether the
implementation reflects a philosophy which is open or closed to specialized
methods. Apache actually isn't particularly open in that regard. One must
hook into an unsupported method error and insert URIQA method handling as
"error resolution". It works. But it's not the most elegant.

Modules such as WebDAV need special accommodation in the core, and thus, the
platform as a whole is not open to specialized methods, either newly
standardized or merely experimental. Whether this closed design is by
oversight or reflects a distinct philisophical position regarding
non-standard methods is not clear. But it is a deficiency nonetheless.

I've found that in most cases, simply using a proxy which can redirect URIQA
requests to a URIQA service is the easiest and cleanest approach -- and has
further merit in that one's semantic web service implementation can remain
modularly separate from one's web service implementation, allowing one to
change either with little to no impact on the other.

Similar criticisms about closed design can be levied against the standard
Java APIs. Use of a non-blessed method throws an exception *before* the
method is set to the HTTP query rather than after, supposedly to "protect"
software developers from accidently specifying a nonstandard method, but
since that exception could just as well be thrown after setting the method,
thus allowing those who know what they are doing to catch and disregard the
exception while still accomplishing the stated goal (and such a change,
requireing that the exception simply be moved 4 lines down in the code, has
been requested, and dismissed) it reflects a particularly rigid
philosophical (or political) stance regarding non-standard methods and does
not reflect openness.

It is for this reason that I mention philosophical and political resistance
to approaches such as URIQA (or WebDAV for that matter) by deliberately
hobbling tools and platforms in a manner which limits or entirely excludes
experimentation and innovation, such that alternative solutions can not be
easily tested and evaluated based on their demonstrable merits.

(fortunately, there are workarounds)

>
> It's not just a server issue of course; we have firewalls, proxies,
> caches, and filtering software to deal with, and applications that
> like to use simple client utilities such as wget (although I admit
> doing HEADs with some of these tools can be a challenge as well). What
> is your experience with URIQA in these situations?

We've never encountered any problem with any of the above. Such phantoms
keep cropping up, and I've repeatedly invited anyone to detail why they feel
that such problems might exist, to offer clear use cases or (ideally)
concrete examples, but have never noted any response of any substance.

My current view (which I'm happy to change in the face of solid evidence) is
that such issues equate to either hypotheticals by folks who are doing
"armchair web architecture", or even worse, "fear mongering" by those with
vested interests in the alternatives to URIQA and related approaches. I
accept that that is a strong statement. Those who would take offense and
disagree are welcome to respond with solid evidence that such problems do,
or clearly can, arise and (importantly) that such problems are significant
to semantic web applications.

(and please note that the above is my personal opinion, and not that of my
employer or necessarily of any of my collegues)

I'm not "religious" about URIQA, or about any particular solution in
general. Honestly, I'm not. I'm very pragmatic and am continually willing to
change my views and methodologies if and when there is clearly a better way,
which takes into consideration the real-world issues relating to (in this
case) metadata authorship and management, scalability, flexibility, and long
term viability and maintenance of real-world solutions.

>
> I hope you and Eran get a chance to duke it out.

I'm happy to review and respond to clear use cases, real-world examples,
fair questions, and worthy arguments on this topic. But I don't have the
time to rehash old arguments which have already been shown to be defective.
I would encourage Eran, or anyone, to search for old threads and study those
before engaging me in any new discussion, as I don't have either the time or
inclination to merely echo what I've said more than frequently enough in the
past, and unfortunately, in the past day or so.

Cheers,

Patrick


>
> Jonathan
>

Received on Thursday, 26 February 2009 04:52:26 UTC