B. Ross Cosc 4f79 1 Forward chaining backward chaining systems: take high-level goal, and prove it by reducing it to a null goal - to reduce it to null, the KB facts input from user are used at some point top-down strategy: Solution --> facts forward chaining or production systems: take all the facts, and use them to fire rules until a high-level rule is proved true This is a good strategy for when there are many feasible solutions, and you want to find one of them Forward-chaining is a "bottom-up" strategy. Facts --> solutions Forward chaining is not directly supported in Prolog (but is easy to implement, because Prolog is a great language)

B. Ross Cosc 4f79 2 Backward chaining Initial Query Knowledge base Facts in working database Q ' Q'' Q''' null (solved) Forward chaining Knowledge base Initial facts Final facts...

B. Ross Cosc 4f79 3 Forward chaining algorithm Productions having form conditions ==> actions where conditions are tests (simple facts, or relations eg. X > Y) actions are : assert(X) - assert a new fact retract(N) - retract fact for condition N retract(all) - retract all facts referenced in conditions arithmetic assignment, unification, IO, etc Algorithm 1. Initial facts are input from user, & put into working database 2. Examine LHS of the productions. If all the conditions are satisfied for a rule, then "fire" it: - execute RHS actions - retract old conditions/facts - input new conditions/facts - do other IO actions, unifications, etc 3. Continue until no rules can be fired.

B. Ross Cosc 4f79 4 instead of a computation tree, what is occurring is that the "state" of the inference is represented by the set of facts in the working database, - each fired rule updates the computation state by changing the current facts - a final state occurs when no more productions can be fired Example implementation: (from Merritt text)

B. Ross Cosc 4f79 5 Enhancements More efficient control: - use heuristics when choosing which rule to fire when more than one is valid - refraction: check that same rule isn't firing over and over - recency: choose rules which use most recently added elements in the database; or least recently used - specificity: choose a rule which employs more conditions, or subsumes another rule eg. if A & B & C then Q if A then R - above require the use of a conflict set: set of rules that are ready to fire - may require rules to be time stamped in order to show when they were added to KB - can apply these ideas to backward chaining as well use that one

B. Ross Cosc 4f79 6 Forward chaining explanation - more difficult than backward chaining, because there is no easy way to save image of the computation - only thing one can do is keep track of which rules fired, and which facts were modified, during the computation

B. Ross Cosc 4f79 7 Mixed mode Many commercial shells combine forward and backward chaining "opportunistic inference" gives much more control to user; however, can be complicated to control Note that the general problem is a theorem proving one example: mixed mode with backward-chaining priority - separate rules into backward and forward groups - use backward chaining until no backward group rule is applicable - then resort to forward chaining until a goal is solved (or perhaps a backward rule becomes invocable) - if both forward and backward chaining stuck, can apply forward chaining inference to backward group - the above is system dependent of course. Many possible variations!

B. Ross Cosc 4f79 8 Mixed mode p Ignizio