From: Frank van Harmelen (Frank.van.Harmelen@cs.vu.nl)
Date: 09/25/01
Richard and Yulin, thanks for your remarks on comparing DQL and RQL. This is exactly the kind of analysis we'll need more of in the course of trying to converge the good parts of the various query-language proposals!
Below is a quick reaction. It is the result of a (quick discussion by email with Jeen Broekstra and Arjohn Kampman, the guys behind Sesame, and therefore of necessity RQL experts.
1. We have the same doubt about the usefulness of DAML+OIL being the syntax for its own query language. But this point has been argued before, so we'll leave it at this.
2. We agree with you that the ICS-FORTH grammar for RQL is too loose. The grammar can be significantly tightened without loosing much expressiveness. That's just a matter of language engineering, there no deep issues here.
3. We think your description of the RQL "from" clause is a bit too ungenerous. You wrote:
"A specification of a collection of RDF statements that
constitute a candidate query answer."
It would be more appropriate to say that the "from"-clause is a regular path expression through the RDF qraph, taking into account the semantics of the RDF Schema primitives. We're still somewhat unclear as to if all of that can be done in DQL. For example:
Q1: "Return all resources of type Publication with author Frank."
RQL:
select R
from Publication{R}.author{N}
where N = "Frank"
QUESTION: what would this look like in DQL?
3. The notion of a Query Premisse is a difference. The meaning is clear, but we are somewhat unclear to the practical usage of this idea.
QUESTION: Can you give us some examples of where that would be useful?
4. You mention the possibility in RQL to ask for the direct descendants of a class/property (subClassOf^) instead of any descendant (subClassOf). You call this "nonmonotonic". The operator does not really add anything interesting to the language. It could be rephrased as a more complicated query without the "^" operator, because RQL contains negation of queries. So the issue is really negation of queries (and their interpretation), not the "^" operator.
We've worked on some applications where the notion of "direct descendant" was crucial, for example semantic navigation through web-sites, where you really wanted to know the most closely related classes, not just all related classes. Another application was query-refinement, where again you wanted to know the smallest possible was to relax/narrow a query, not just all.
QUESTION: would you agree that such an operator (or any other way to obtain the same effect) is crucial in practical DAML+OIL use?
5. You speak about "RQL allowing disjunctions and negations of RDF statements".
We don't understand what you mean. It is true (and useful) that RQL allows disjunctions and negations of >*queries*< (and it is this that reduces "^" to syntactic sugar), but that's different from "disjunctions and negations of RDF statements".
As you see, there is more in your analysis with which we agree then disagree. Let's hope this leads to a useful integration of features (you already pointed at possibilities to integrate a select clause in DQL (which will certainly also help to make the database-folk happier!)
Frank
----
(with significant input from Jeen Broekstra and Arjohn Kampman)
This archive was generated by hypermail 2.1.4 : 04/02/02 EST