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

Sorry Richard. For some reason, this particular message got trapped by my
spam filter. No clue why.

Our server sw.nokia.com was undergoing some maintenance upgrades and not all
of the nodes in the farm were fully configured.

It should be working fine now.

Cheers,

Patrick




On 2009-02-26 12:41, "ext Richard Cyganiak" <richard@cyganiak.de> wrote:

> Patrick,
>
> I want to play. Is there a demo server somewhere on the Web that
> responds to MGET requests?
>
> I googled and found some URIs at sw.nokia.com that smelled like they
> should be URIQA-enabled, but some fooling around with curl -X and
> telnet didn't produce any useful responses. Hard to tell if it's just
> me being dense.
>
> (Let me tell you that URIQA might be more successful if its proponents
> were producing more demos and running code examples and less words!)
>
> Cheers,
> Richard
>
>
> On 26 Feb 2009, at 04:54, <Patrick.Stickler@nokia.com>
> <Patrick.Stickler@nokia.com
>> wrote:
>
>>
>>
>>
>> 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 Friday, 27 February 2009 16:18:41 UTC