W3C home > Mailing lists > Public > www-rdf-rules@w3.org > September 2001

Re: What is an RDF Query?

From: Eric Prud'hommeaux <eric@w3.org>
Date: Thu, 13 Sep 2001 16:27:53 -0400
To: David Allsopp <d.allsopp@signal.QinetiQ.com>
Cc: www-rdf-rules@w3.org
Message-ID: <20010913162753.D27938@w3.org>
On Wed, Sep 12, 2001 at 10:40:56AM +0100, David Allsopp wrote:
> pat hayes wrote:
> > OK, I took a look at http://lists.w3.org/Archives/Public/www-rdf-rules/#terms
> > and found this:
> > ----
> > rule
> >         Expression of query and assertion that causes the automatic
> > insertion of asserted statements wherever the query is matched.
> > -----
> > which may help to explain the (my) confusion. This notion of 'rule'
> > doesn't make sense to me. Why would matching a *query* produce the
> > insertion of *statements*? 

Be they in the original dataset or in temporary database from which
the query response is culled, the consequence of a rule must be noted
in order to be useful. I called that operation "inserting", perhaps
wrongly (or incoherently). By the terms I used,
  if P then Q
can be described as a rule made of a query P and an assertion Q.

>                              If we were to use a rule (in the usual
> > sense, now, not Eric's) in forward inference, then it would match an
> > assertion and produce a new assertion (as in inferring Q from P and
> > (if P then Q) ) , and if we are using it in backwards mode then it
> > would match a query and produce a new query (as in  going from ?Q and
> > (if P then Q) to ?P). These are really the 'same' inference,
> > logically speaking - modus ponens - but done in different
> > 'directions'. But I can't think of any way to take a rule, match it
> > to a query, and get an assertion.

In my terms, that would be
  (query1 + assertion1) + query2 => assertion2.
  |------ rule1 ------|  |------ rule2 -------|

I agree, I don't see this as useful except in doing rules about rules
which would be used proof checking or other mechanisms to control the
behaviour of an inferencing engine. Even there, I don't believe that
rule1 is treated like a rule, ie. evaluated, so much as considered as
a set of statements in matching query2.

> No, nobody's saying one should match a _rule_ against a _query_, I
> think.
> As Pat says, the antecedent of a rule matches assertions. I think some
> people regard the antecedent as a query over the fact base ("Is this
> assertion in the fact base? If so, assert the consequent").

I meant the query and assertion to be tied together. I state a rule in
terms of a query and set of assertions.

Looking for queries to match rules, as alluded to above, seems like a
way one would optimize a backward chaining query to limit the working
  dataset has a statements and two rules:
    if P then Q
    if Q then R
  but has not done forward chaining. The query
  causes the inferencer to look for R in the dataset. The only
  candidate is the rule "if Q then R" so it looks for Q in the
  dataset etc.
I would say this is a perfectly reasonable strategy, but I was only
trying to characterize those rules "if P then Q" and "if Q then R"
in terms that would elucidate the parallels between "if P", "if Q"
and "R?".

> In implementation terms, the antecedent may literally involve a query,
> because to match it against an assertion one has to extract assertions
> from a fact base (i.e. query a database looking for matching
> assertions). One might then speak of "matching the query" i.e.
> succeeding in matching the rule's antecedent with an assertion.  I think
> this is common (though clearly confusing) usage...

I think the reason it is/could be useful is that the query part of
rules can be expressed in the same language as the query part of
queries (which would be the greater part).

> Perhaps the confusion lies in "query" as an expression (where some
> syntax, such as a question mark, indicates a question), and "query" as a
> implicit process, where assertions are compared.

Is there a difference beyond the expectation of what to do with the


Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Thursday, 13 September 2001 16:27:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:49:36 UTC