Re: What is an RDF Query?

> > > > >I agree that RDF queries and RDF rule premises
> > > >
> > > > Er.....actually, rule consequents/conclusions are more like queries
> > > > than rule premises are. Is that what you meant?
> > >
> > >Um, no.
> > >
> > >Here's a rule:  If Ralph is in his office, then Ralph is at MIT.
> > >                    \                  /         \           /
> > >                     \                /           \         /
> > >                          Premise                 Conclusion
> > >                        (Antecedent)             (Consequent)
> > >
> > >We could make either part into a query:
> > >       Is Ralph in his office?
> >
> > There is no way to answer that, given this rule. The rule simply
> > doesn't connect to this query in any way.
> >
> > >       Is Ralph at MIT?
> >
> > He is if he is in his office, otherwise you don't know (from the rule)
>
>Ah-ha!   I see what you think I'm talking about now.
>
> > See any logic textbook, Sorry , but this is really very basic stuff.
>
>Well, yes.  I was going to say the same thing to you, but I knew
>better.  :-)   Everything you said in your e-mail here was, indeed,
>elementary.
>
>What I think you think I'm talking about is querying a rule base.
>(Or, more precisely, querying the entailment closure of a set of
>axioms.)  If I were trying to do that, I would probably use backward
>chaining.  Doing that, I would do what you're talking about: I would
>look for rule conclusions which looked like

unified with, to be precise. But go ahead....

> my goal query.  And in
>that effort, I would be taking advantage of some similarity between
>queries and rule conclusions.    That's what you're talking about,
>right?

Right. So are most other people, by the way :-)

>What I was talking about (and what I'm pretty sure what Eric
>Prud'hommeaux was talking about when he started this) is even
>simpler.  Here's our knowledge base:
>
>   Fact:  Ralph is in his office.
>   Fact:  The Sun is shining.
>    ...
>   Rule:  If Ralph is in his office, then Ralph is at MIT.
>
>You're jumping ahead and imagining I'll ask "Is Ralph at MIT?" but in
>fact I'm asking something much simpler.  I'm asking "Is Ralph in his
>office".  Answering that query doesn't involve the rule (obviously).

Right, in fact it has nothing to do with rules at all (except in the 
sense that an atomic assertion might be called a kind of ur-rule with 
one consequent and no antecedents.)

>And then I start to think -- hey, I could forward-chain that rule!

You could, indeed (though see below), but then *that* has nothing to 
do with making queries. So why are you talking about this topic under 
this thread?

>I
>could see if it's premise is true so I can maybe make some inferences!
>And if I do that, the first thing I'll do is ask "Is Ralph in his
>office?"

BUt why would you pick on that fact as the first thing to think 
about? Wouldnt the only reason for choosing that fact (from, in a 
realistic example, maybe several hundred or several thousand facts) 
would be because you were led to it by a process of backward 
('goal-oriented' as is sometimes said) chaining from a query, eg say 
the question of whether Ralph was at MIT? If you just go generating 
all forward inferences, you will run out of memory pretty soon.

>so I know whether to infer he's at MIT.

Not quite. That would actually infer it for you. BUt to detemine 
whether or not to do the inference, without actually doing it, would 
be a much more subtle kind of operation (which nobody knows how to 
do, as far as I know.) The trouble with forward inference is 
precisely that it works blind, and tends to overwhelm you with 
irrelevant truths precisely because you don't know whther or not to 
infer anything in particular; and forward inference does it all, 
whether you wanted to or not.

>
>This is, of course, very basic stuff (for someone familiar with formal
>logic).
>
>Eric was saying that asking "Is Ralph in his office?" is the same
>thing whether it's being done directly because of a user's query or as
>part of a rule-chaining processes.

Careful. That is a *question*. You cannot correctly infer the 
question Q? from the question P? and the rule (if  P then Q); so the 
rule-chaining process that can generate a new *question* has to be 
backward chaining, not forward chaining. Assertions go forward, 
questions go backwards. Forward chaining might generate "Ralph is in 
his office", but it can't generate a question.

>Eric's RDF software (algae) and
>Tim B-L's RDF software (cwm) both do forward-chaining, and I suspect
>they use the same code for user queries and rules.

If they do forward chaining on queries then they are invalid, and 
therefore probably broken. Really, I am not impressed by observations 
about what some piece of code does, no matter who wrote it. The fact 
that a piece of code does something proves nothing. Code can be made 
to do anything; its easy to write code to generate total nonsense.

>So I think your answer is "well, of course they're the same thing."
>They're so obviously the same thing that you figured we were talking
>about something else (like matching queries with rule conclusions, in
>doing backward chaining).   Am I right?

At this point I don't know what you are talking about.

The only valid way to relate rules to queries is to use the rules ' 
backwards' (match conclusion, generate antecedents) to generate new 
queries from old ones. The only way to relate rules to assertions is 
to use rules 'forward' (match antecedents, infer conclusion) to 
generate new assertions from old ones. Both of these operations can 
be unified into a single process, in ways that have been in textbooks 
now for about 30 years or so. I expect that cwm and algae do pretty 
much the same thing that everyone else's inference engines do, since 
that's about the only sensible way to do it. However, what y'all 
*say* about what they do seems completely confused to me.

>
>In fact, I think they're probably the same thing at all when you get
>into enough engineering details.  But in the abstract, they are.

(I presume theres a missing negation in there somewhere. )

Actually they  can be unified (pardon the pun) at both the abstract 
and engineering senses. But they are still distinct ideas.

Pat

---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 11 September 2001 16:34:44 UTC