- From: pat hayes <phayes@ai.uwf.edu>
- Date: Tue, 11 Sep 2001 19:33:03 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: www-rdf-rules@w3.org
> > So why are you talking about this topic under > > this thread? > >Because this thread started when you took exception to my agreeing >that Eric's claim was indeed on track. Eric had said: > > In the charter terms, I make the bold statement that rules are > composed of queries and assertions. This is intended to clarify why > both communities have been inducted into the same list. In > implementing algae [2], I used the variables bindings from a query > to compose assertions. Does this match the experience of others? > >Do you agree Eric is on track? Hm, good question. Basically, I don't know, since I don't know exactly what he is saying. I can read those words in a way that does make sense. One could say that a rule - logically, an implication - consists of premises which are assertions, in a sense, and a conclusion which is a query, in a sense. If that is what Eric means, then I agree he is on track; but its a potentially very misleading way of saying it. Taken literally it is false, since the rule doesnt actually assert its antecedents, or query its conclusions (or vice versa). It would be better to say that the rules act as a kind of bridge between assertions (which match their antecedents) and queries (which match their conclusions), rather than that they are *composed* of them. If I try to take that claim literally then I can't really make sense of it. What sense of 'composed' is intended? Maybe an example would help to clarify the claim. Can we see a simple rule and the way it is composed of assertions and queries? > I think so, when you say: > > > >In fact, I think they're probably [not] the same thing at all when you get > > >into enough engineering details. But in the abstract, they are. > > -- sandro > > Actually they can be unified (pardon the pun) at both the abstract > > and engineering senses. But they are still distinct ideas. > > -- pat > >So why this whole argument? I guess you wanted to make the companion >point that rule conclusions are also like queries, in that in backward >chaining one attempts to unify them. > >Both points combine to say we have to keep our query language >unifyable with our assertion language if we want rules to work. >Perhaps that was obvious. Well, that is either obvious (if we think of rules as logical implications) or false (with somewhat different, more directly computational, senses of 'rule' and 'query'). I'm not sure which, but either way its hardly worth saying very loud. > > >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. > >I wasn't saying anything about infering questions. What do you mean by 'as part of a rule-chaining process', if not some kind of inference? >You seem to be >looking for outrageous claims when I'm only making outrageously >obvious ones (in this thread, at least). My great claim (Eric's >claim) might be better stated thus: unification is used BOTH in >answering queries in non-rule systems AND in applying rules in >rule-based systems. AND in passing parameters to function calls AND in doing both forward and backward inference. >Pretty cutting-edge stuff, huh? :-) > > >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. > >I wasn't trying to prove that forward chaining works! I was just >saying that in the RDF community, some people who are doing RDF Query >are dabbling with rules. Forward chaining is a bit more obvious, so >they're trying that first. Stefan Decker and I are the only people >I've noticed talking about doing backward chaining. There are >probably others (I can't possibly keep track) but I don't think any of >the RDF database systems available has backward chaining. > >This list (I think) combines people to whom backward chaining is like >walking and people to whom it's more like riding a unicycle: sure you >can do it with enough work, but why bother? Its far easier to implement than forward chaining. It can be done with a stack just like recursion (which is a special case). No unicycles required. Why bother? Because it works (try Prolog). Making forward chaining work in anything but toy domains is serious AI business. If backward chaining seems hard, try band-limited progressive forward chaining with a heuristic evaluation function. 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 20:33:09 UTC