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

RE: What is an RDF Query?

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 18 Sep 2001 10:47:45 -0500
Message-Id: <p05101001b7cd15bfccb5@[]>
To: "Wagner, G.R." <G.R.Wagner@tm.tue.nl>
Cc: www-rdf-rules@w3.org
>  >>  In implementation terms, the antecedent may literally involve a
>>>   because to match it against an assertion one has to extract
>>>   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 hope it's not common, as it certainly is confusing. Its like
>>  calling the handle of hammer the "head" because it's the part you
>>  hold onto when you hit nails with the head.
>>  Look, consider the simple rule (if P then Q) again. Sure, its the
>>  case that *if* you start with a query of Q, then this rule can
>>  generate a query of P, so you might call the P in the rule the
>>  'query-ish' part. But if you use the same rule with an assertion of P
>>  (not a query) then it will generate an assertion of Q. In the latter
>>  case, there aren't any queries involved at all.
>I think you miss the point. Notice that in a KR system,
>the query language is generally more expressive than the
>input/assertion language.

Not in most KR systems with which I am familiar.

>E.g. in Prolog you may pose a
>disjunctive query, but you must not assert a disjunction.

Ah, I see what you mean. This is almost entirely a debate about 
terminology, and you seem to have introduced another usage. I would 
say that the languages of queries and rules in Prolog were 
*identical*: both consist of Horn clauses. The asymmetry that you see 
is built into the definition of 'Horn clause'. I actually disagree 
with what you say; every Prolog clause is asserted, and all the 
non-atomic clauses are disjunctions.  A standard Prolog interpreter 
propagates queries by backward chaining, and never makes new 
assertions. What you are calling an 'assertion' is the consequent of 
a Horn clause, which must be atomic by definition.

>In SQL, you may ask a universally quantified query, but you
>cannot assert/INSERT a universally quantified sentence. Exactly
>the same applies to the languages of antecedents and consequents
>in rules of the form (if P then Q) in a KR system. P may be
>more expressive than Q in the same way as a query may be more
>expressive than an assertion.

Yes, I agree. And that is not surprising, of course, since if one is 
using the rule in backward chaining, then its consequent should match 
(part of) a query and its antecedent then become a new query; so one 
would expect that the formats of queries and antecendents should line 
up in this way. But that is only one way to use a rule, even if it is 
a very common one. My point was only that we should not confuse the 
terminologies  antecendent/consequent and query/assertion, since they 
refer to different categories of thing.

>When you check P, you decompose
>it into subformulas from the assertion language and then
>match it against the corresponding expressions in your
>knowledge base,

When doing forward reasoning, yes.

>whereas the expressivity of an assertion Q
>is typically restricted by the need to have an efficiently
>queryable KB (this excludes, in particular, disjunction and
>existential quantification in the assertion language).
>>  The point is that the *very same* expression can be both asserted and
>>  queried; being an assertion or a query are not syntactic categories.
>Sure can the very same expression be both asserted and queried,
>but only if it is from the intersection of the query and the
>assertion language.

No, now you are missing my point, which has nothing to do with the 
kind of language involved. There are not two distinct languages, but 
one language with  two different attitudes towards it.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 18 September 2001 11:47:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:13 UTC