Re: What is an RDF Query?

Pat Hayes wrote:

> >>  > 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).
> 
> NO, that's OK. The part I'm having trouble with here is why the
> initial trigger was called a *query* instead of an *assertion*. If I
> assert P and I know that (P implies Q) then its obviously correct to
> infer Q and assert it. But even if I know that (P implies Q), I'm not
> entitled to infer Q from P's being *queried*. If I know that men are
> mammals, and someone *asks* me if Joe is a man, I shouldn't conclude
> that Joe is a mammal. Maybe the answer to the question was 'No, Joe
> is a parrot'

The reason calling the trigger a query made sense to me is that I
visualise the situation as follows:
I have a rule engine and set of rules. There is a separate knowledge
base of assertions somewhere, on disk or on the network. 'I' (the rule
engine) know that (P implies Q). But has P been asserted, and can I
therefore infer Q? That's in the knowledge base, so I have to *query*
the knowledge base in order to tell whether P has been *asserted*.

Others evidently visualise the situation quite differently, with
assertions and rules integrated into one system, I think; so there's no
need to find out whether P has ben asserted - you just *know*.


> >By the terms I used,
> >   if P then Q
> >can be described as a rule made of a query P and an assertion Q.
> 
> So you are using the term 'query' to indicate the antecedent of a
> rule, ie as a syntactic category in the rule language syntax, is that
> right? That is likely to create a lot of misunderstanding, I would
> suggest.

I think it already has 8-). As you and Peter have said, we'd better
stick to antecedent.


> >>  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 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.

Agreed, if you "just know" that P has been asserted. If the rule engine
and the knowledge base are separated in some way then the former has to
get information from the latter in order to process the rule; I believe
this is why some people think of the P in the rule (if P then Q) as a
query.  I accept that this is confusing terminology though.

Regards,

David.
-- 
/d{def}def/u{dup}d[0 -185 u 0 300 u]concat/q 5e-3 d/m{mul}d/z{A u m B u
m}d/r{rlineto}d/X -2 q 1{d/Y -2 q 2{d/A 0 d/B 0 d 64 -1 1{/f exch d/B
A/A z sub X add d B 2 m m Y add d z add 4 gt{exit}if/f 64 d}for f 64 div
setgray X Y moveto 0 q neg u 0 0 q u 0 r r r r fill/Y}for/X}for showpage

Received on Wednesday, 19 September 2001 05:48:21 UTC