W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003

Re: RDF query and Rules - my two cents

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Sun, 23 Nov 2003 11:51:57 +0200
Cc: <www-rdf-interest-request@w3.org>, "Graham Klyne" <GK@ninebynine.org>, "Jim Hendler" <hendler@cs.umd.edu>, "Dan Brickley" <danbri@w3.org>, <www-rdf-rules@w3.org>, <www-rdf-interest@w3.org>
To: "ext Danny Ayers" <danny666@virgilio.it>
Message-Id: <ACF6E474-1D9A-11D8-92B5-000A95EAFCEA@nokia.com>


On Friday, Nov 21, 2003, at 20:45 Europe/Helsinki, ext Danny Ayers 
wrote:

>
> Ok, I disagree on several of the details in your last response, but I 
> won't
> quibble. I think the list of 4 server requirements you gave (below) 
> are the
> key, and they do nobble the mimetype approach as a general solution. A 
> good
> set of gauntlets for any other proposals to run.
>

I agree. And I'd like to see them (or something analogous to them) 
written
into the charter of the RDF Query WG. And I left out a few others, that 
are as
important as the other 4:

5. An agent should be able to discern, from the response header alone,
whether its request for a description, rather than (some other form of)
representation, was understood by the server and if successful, should 
be
able to presume that the response contains a description of the 
resource.
The agent should not have to examine the content of the response to 
attempt
to determine whether it is a description or something else.

6. The solution adopted, should work in a consistent fashion for 
operations
equal or analogous to the methods GET, PUT, and DELETE.

7. An agent, having a URI meaningful to the HTTP protocol, should be 
able
to obtain a description of the denoted resource via a single server 
request
and having no additional knowledge other than the URI itself.

These requirements together have never been met by any proposed header
based solution, because, even though they might work with GET, they fail
requirements #2 and #6 for PUT and DELETE operations, and also, usually
#5 and/or #7 as well.

I consider the URIQA extensions to be the absolutely minimal extensions
necessary to meet all of these requirements.

But if someone is able to propose a solution that meets these 
requirements
without recourse to new methods, I'd love to hear it.

> This is of course assuming the transport of a description in the form 
> you
> describe is as important as you suggest. It (or something similar) 
> would
> certainly make a lot of operations a lot easier, and oil the cogs.
>
> I still hold out hope that additional engineering of web servers won't 
> be
> necessary (and rather we didn't just drop into tunnelling the simpler
> queries).

If an RDF Query WG, or anyone else for that matter, is able to crack 
this
nut without introducing new methods, I'm all for that. I'm not 
religiously
committed to a particular solution -- simply to *some* solution that 
meets
the minimum requirements -- but unless and until someone comes up with
something better, URIQA works very nicely and does the job for us.

> But failing that I look forward to your instructions for deploying
> URIQA ;-)
>

I will be releasing as open source the code for the Nokia Semantic Web 
Server,
which provides a complete URIQA enabled server implementation, based on
Intellidimensions RDF Gateway product. I will also be releasing a 
simplified
implementation, in Java, based on Jena. Both should be available in 
early/mid
January.

Regards,

Patrick


> Cheers,
> Danny.
>
> ...
>>> That's a debatable point. The Concise Bounded Resource Description 
>>> of a
>>> resource could be seen as simply just another representation of that
>>> resource.
>>>
>>
>> Yes. And I point that out in the URIQA spec.
>>
>> But the semantics of interacting with descriptions is specialized
>> and different in significant ways from the semantics of interacting
>> with arbitrary representations.
>>
>> When communicating with a server:
>>
>> 1. One must be able to indicate to the server that the request 
>> concerns
>>     a description and not a(nother form of) representation.
>>
>> 2. One must be able to ensure that if the server has no clue what a
>>     description is, that it won't do something to a(nother form of)
>>     representation.
>>
>> Furthermore,
>>
>> 3. A description is an abstraction for which one should
>> be able to use the full richness of web functionality, e.g. content
>> negotiation, etc. in conjunction with whatever SW extensions are
>> deployed.
>>
>> 4. The distinction to be made in #1 above should not depend on
>>     any part of the URI itself (i.e. no special suffixes, etc.)
>>
>> Thus, #2 above rules out headers with PUT/DELETE, and #3 rules out
>> using MIME types or similar hacks.
> ...
>> In short: URIQA and the RDF Net API are two different kinds of
>> protocols.
>> Both are needed.
>
Received on Sunday, 23 November 2003 04:55:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:03 GMT