1 / 95

Introduction to Rule-Based Reasoning

Introduction to Rule-Based Reasoning. Jacques Robin. Outline. Rules as a knowledge representation formalism Common characteristics of rule-based systems Roadmap of rule-based languages Common advantages and limitations Example practical application of rules: declarative business rules

pete
Download Presentation

Introduction to Rule-Based Reasoning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to Rule-Based Reasoning Jacques Robin

  2. Outline • Rules as a knowledge representation formalism • Common characteristics of rule-based systems • Roadmap of rule-based languages • Common advantages and limitations • Example practical application of rules: declarative business rules • History of rule-based systems • Production Systems • Term Rewriting Systems • Logic Programming and Prolog

  3. Rules as a Knowledge Representation Formalism • What is a rule? • A statement that specifies that: • If a determined logical combination of conditions is satisfied, • over the set of an agent’s percepts • and/or facts in its Knowledge Base (KB) • that represent the current, past and/or hypothetical future of its environment model, its goals and/or its preferences, • then a logico-temporal combination of actions can or must be executed by the agent, • directly on its environment (through actuators) or on the facts in its KB. • A KB agent such that the persistent part of its KB consists entirely of such rules is called a rule-base agent; • In such case, the inference engine used by the KB agent is an interpreter or a compiler for a specific rule language.

  4. Fact Base: • Volatile knowledge • Dependent on problem instance • Data Rule-Based Agent Environment Sensors Ask Tell Retract • Rule Engine: • Problem class independent • Only dependent on rule language • Declarative code interpreter or compiler Ask • Rule Base: • Persistant intentional knowledge • Dependent on problem class, not instance • Declarative code Effectors

  5. Rule Languages: Common Characteristics • Syntax generally: • Extends a host programming language and/or • Restricts a formal logic and/or • Uses a semi-natural language with • closed keyword set expressing logical connectives and actions classes, • and an open keyword set to refer to the entities and relations appearing in the agent’s fact base; • Some systems provide 3 distinct syntax layers for different users with automated tools to translate a rule across the various layers; • Declarative semantics: generally based on some formal logic; • Operational semantics: • Generally based on transition systems, automata or similar procedural formalisms; • Formalizes the essence of the rule interpreter algorithm.

  6. Rule Languages: General Advantages • Human experts in many domains (medicine, law, finance, marketing, administration, design, engineering, equipment maintenance, games, sports, etc.) find it intuitive and easy to formalize their knowledge as a rule base • Facilitates knowledge acquisition • Rules can be easily paraphrased in semi-natural language syntax, friendlier to experts averse to computational languages • Facilitates knowledge acquisition • Rule bases easy to formalize as logical formulas (conjunctions of equivalences and/or implications) • Facilitates building rule engine that perform sound, logic-based inference • Each rule largely independent of others in the base (but to precisely what degree depends highly of the rule engine algorithm) • Can thus be viewed as an encapsulated, declarative piece of knowledge; • Facilitates life cycle evolution and composition of knowledge bases • Very sophisticated, mature rule base compilation techniques available • Allows scalable inference in practice • Some engines for simple rule languages can efficiently handle millions of rules

  7. Rule Languages: General Limitations • Subtle interactions between rules hard to debug without: • sophisticated rule explanation GUI • detailed knowledge of the rule engine’s algorithm • Especially serious with: • Object-oriented rule languages for combining rule-based deduction or abduction with class-based inheritance; • Probabilistic rule languages for combining logical and Bayesian inference; • But purely logical relational rule language do not naturally: • Embed within mainstream object-oriented modeling and programming languages • Represent inherently procedural, taxonomic and uncertain knowledge • Current research challenge: • User-friendly reasoning engine for probabilistic object-oriented rules

  8. Classic Imperative OO Implementation Classic 3-Tier Information System Architecture Rule-Based Implementation Imperative OO Language GUI API Imperative OO Language GUI API GUI Layer Easier to reflect frequent policy changes than imperative code Embedded Production Rule Engine Production Rule Base Imperative OO Program Business Logic Layer Imperative OO Host Language Imperative OO Language SQL API Imperative OO Language SQL API Data Layer Generic Component Reusable in Any Application Domain Business Rules • Example of modern commercial application of rule-based knowledge representation

  9. Semi-Natural Language Syntaxfor Business Rules • Associate key word or key phrase to: • Each domain model entity or relation name • Each rule language syntactic construct • Each host programming language construct used in rules • Substitute in place of these constructs and symbols the associated words or phrase • Example: “Is West Criminal?” in semi-natural language syntax: IF P is American AND P sells a W to N AND W is a weapon AND N is a nation AND N is hostile THEN P is a criminal IF nono owns a W AND W is a missile THEN west sells W to nono IF W is a missile THEN W is a weapon IF N is an enemy of America THEN N is hostile

  10. Rewrite Rules Logic Programming ISO Prolog Otter Concurrent Prolog Transaction Logic HiLog Production Rules EProver Courteous Rules Maude CLP(X) CCLP(X) CHR OPS5 ELAN Pure OO Languages Rule-Based Constraint Languages CHRV Frame Logic CHORD NeOPS Smalltalk UML QVT CLIPS C++ Flora MOF OCL Web Markup Languages JEOPS JESS Java SWSL OO Rule Languages RuleML XML XSLT Roadmap of Rule-Based Languages

  11. Rewrite Rule RHS * LHS Term * args {disjoint, complete} {disjoint, complete} Functional Term Non-Functional Term Ground Term Non-Ground Term Function Symbol Constant Symbol Variable Rewrite Rules: Abstract Syntax Rewrite Rule Base plus(X,0)  X fib(suc(suc(N))) plus(fib(suc(N)),fib(N))

  12. : Rewrite Rule Base • : Unifying Set of Pairs: • Instantiated Rule • Instantiated Sub-term [ Matching Pair Set Empty ] Unify LHS of Rewrite Rule Base against sub-terms of Term Pick one Pair Set [ Else ] T : Term [ Matching Pair Set Singleton ] • : Pair • Instantiated Rule R • Instantiated Sub-Term S Substitute Sub-Term S in Term T by RHS of Rule R Rewrite Rules: Operational Semantics

  13. plus(X,0)  X plus(X,suc(Y))  suc(plus(X,Y)) fib(0)  suc(0) fib(suc(0))  suc(0) fib(suc(suc(N))  plus(fib(suc(N)),fib(N)) fib(suc(suc(suc(0)))) w/ rule e plus(fib(suc(suc(0))),fib(suc(0))) w/ rule d plus(fib(suc(suc(0))),suc(0)) w/ rule b suc(plus(fib(suc(suc(0))),0)) w/ rule a suc(fib(suc(suc(0)))) w/ rule e suc(plus(fib(suc(0)),fib(0))) w/ rule c suc(plus(fib(suc(0)),suc(0))) w/ rule b suc(suc(plus(fib(suc(0)),0))) w/ rule a suc(suc(fib(suc(0)))) w/ rule d suc(suc(suc(0))) Rewrite Rule Base Computation Example

  14. Conditional Rewrite Rules:Abstract Syntax Rewrite Rule Base Rewrite Rule X = 0  Y = 0 | X + Y  0 RHS * Condition LHS * 2 Equation Term • Rule with matching LHS can only be fired if condition is also verified • Proving condition can be recursively done by rewriting it to true

  15. Rewrite Rule Base: criminal(P)  american(P)  weapon(W)  nation(N)  hostile(N)  sells(P,N,W) sells(west,nono,W)  owns(nono,W)  missile(W) hostile(N)  enemy(N,america) weapon(W)  missile(W) owns(nono,m1)  missile(m1)  american(west)  nation(nono)  enemy(nono,america)  true A  B  B  A A  A  A Term: criminal(P) american(P)  weapon(W)  nation(N)  hostile(N)  sells(P,N,W) w/ rule a american(P)  weapon(W)  nation(N) hostile(N) owns(nono,W)  missile(W) w/ rule b american(P)  weapon(W) nation(N) enemy(N,america) owns(nono,W)  missile(W) w/ rule c american(P)  missile(W)  nation(N)  enemy(N,america)  owns(nono,W) missile(W) w/ rule d american(P)  missile(W)  nation(N)  enemy(N,america)  owns(nono,W) w/ rule g ... w/ rule f owns(nono,W) missile(W)  american(P)  nation(N)  enemy(N,america) w/ rule f truew/ rule e Rewrite Rule Base Deduction Example:Is West Criminal?

  16. Rewriting Systems: Practical Application • Theorem proving • CASE: • Programming language formal semantics • Program verification • Compiler design and implementation • Model transformation and automatic programming • Data integration • Using XSLT an XML-based language to rewrite XML-based data and documents • Web server pages and web services (also using XSLT)

  17. * Production Rule Base Production Rule Right-Hand Side (RHS) * Action Left-Hand Side (LHS) Arithmetic Calculation Fact Base * Fact 2..* And-Or Formula Connective: enum{and,or} Atom Fact Base Update Operator: enum{add,delete} Predicate Symbol Functor args Non-Ground Atom Non-Functional Term Ground Atom Constant Symbol Variable Production Rules: Abstract Syntax IF (p(X,a) OR p(X,b)) AND p(Y,Z) AND q(c) AND X <> Y AND X > 3.5 THEN Z = X + 12 AND add{r(a,c,Z} AND delete{p(Y,Z)} Arithmetic Predicate Symbol Arithmetic Constant Symbol

  18. Production System Architecture Fact Base Fact Base Management Component Pattern Matching Component Action Execution Component Rule Firing Policy Component Rule Base Host Language API Candidate Rules

  19. [Matching Instantiated Rule Set Empty] Pick one Instantiated Rule to Fire Match LHS of Rule Base against Fact Base Matching Instantiated Rule Set [Else] Rule Base Fact Base [Matching Instantiated Rule Set Singleton] Selected Instantiated Rule Execute in Sequence Actions in RHS of Selected Instantiated Rule Production Rules: Operational Semantics

  20. Conflict Resolution Strategies • Conflict resolution strategy: • Heuristic to choose at each cycle which of the matching rule set to fire • Common strategies: • Follow writing order of rules in rule base • Follow absolute priority level annotations associated with each rule or rule class • Follow relative priority level annotations associated with pairs of rules or rule classes • Prefer rules whose LHS match the most recently derived facts in the fact base • Prefer rules that have remained for the longest time unfired while matching a fact • Apply control meta-rules that declaratively specify arbitrarily sophisticated strategies

  21. Production Rule Base: IF american(P) AND weapon(W) AND nation(N) AND hostile(N) AND sell(P,N,W) THEN add{criminal(P)} IF owns(nono,W) AND missile(W) THEN add{sells(west,nono,W) IF missile(W) THEN add{weapon(W)} IF enemy(N,america) THEN add{hostile(N)} Initial Fact Base: owns(nono,m1) missile(m1) american(west) nation(nono) enemy(nono,america) nation(america) Production Rule Base Example:Is West Criminal?

  22. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(W) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(W) enemy(N,america) owns(nono,W) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  23. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(W) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(m1) enemy(nono,america) owns(nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  24. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(m1) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(W) enemy(nono,america) owns(nono,W) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  25. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(m1) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(m1) enemy(nono,america) owns(nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  26. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(m1) nation(N) hostile(nono) sells(P,N,W) sells(west,nono,W) missile(W) owns(nono,W) american(west) missile(m1) nation(nono) enemy(nono,america) owns(nono,m1) nation(america)

  27. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(m1) nation(N) hostile(nono) sells(P,N,W) sells(west,nono,W) missile(m1) owns(nono,m1) american(west) missile(m1) nation(nono) enemy(nono,america) owns(nono,m1) nation(america)

  28. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(P) weapon(m1) nation(N) hostile(nono) sells(P,N,W) sells(west,nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  29. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(P) american(west) weapon(m1) nation(nono) hostile(nono) sells(west,nono,m1) sells(west,nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  30. Production Rule Inference Example:Is West Criminal? criminal(west)? criminal(west) weapon(m1) hostile(nono) sells(west,nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  31. Production Rule Inference Example:Is West Criminal? criminal(west)? yes criminal(west) weapon(m1) hostile(nono) sells(west,nono,m1) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  32. Properties of Production Systems • Confluence: • From confluent rule base, same final fact base is derived independently of rule firing order • Makes values of queries made to the system independent of the conflict resolution strategy • Termination: • Terminating system does not enter in an infinite loop; • Example of non-termination production rule base: • Initial fact base: p(0) • Production rule base: IF p(X) THEN Y = X + 1 AND add{p(Y)} • Any production system which conflict resolution strategy does not prevent the same rule instance to be fired in two consecutive cycles is trivially non-terminating.

  33. Production System Inference Sequential conjunction of actions in rule RHS Non-monotonic reasoning due to delete actions Matching only Datalog atoms (i.e., atoms which arguments are all non-functional terms) Matching ground fact atoms against non-ground atoms in rule LHS And-Or atom Neither sound nor complete inference engine Lifted Forward Chaining Unique conclusion in Horn Clause Monotonic reasoning Unifying arbitrary first-order atoms, possibly functional Unifying two arbitrary atoms, possibly both non-grounds Sound and refutation-complete Production System Inference vs.Lifted Forward Chaining Common characteristics: • Data driven reasoning • Requires conflict resolution strategy to choose: • Which of several matching rules to fire • Which of several unifying clauses for next Modus Ponens inference step

  34. Production Rule Base Production Rule Right-Hand Side (RHS) * * Action * Fact Base Fact Left-Hand Side (LHS) HPL Boolean Operation HPL Operation * HPL Data Structure HPL Ground Data Structure 2..* args And-Or Formula Connective: enum{and,or} Fact Base Update Operator: enum{add,delete} HPL Operator HPL Boolean Operator Embedded Production System: Abstract Syntax

  35. Generalized Production Rules: ECA Rules • Event-Condition-Action rule: extension of production rule with triggering event external to addition of facts in fact base • Only the rule subset which event just occurred is matched against the fact base • Events thus partition the rule base into subsets, each one specifying a behavior in response to a given events Event Condtion Action Rule LHS RHS Event Agent’s Percept HPL Boolean Operation

  36. Production System Inference Fact base implicitly conjunctive Matching only Datalog atoms (i.e., atoms which arguments are all non-functional terms) Matching ground fact atoms against non-ground atoms in rule LHS And-Or atom Production Rules vs. Rewriting Rules Common characteristics: • Data driven reasoning • Requires conflict resolution strategy to choose: • Which of several matching rules to fire • Which of several rules with an LHS unifying with a sub-term • Non-monotonic reasoning due to: • Fact deletion actions in RHS • Retraction of substituted sub-term • Tricky confluence and termination issues Term Rewriting • Reified logical connectives in term provide full first-order expressivity • Unifying arbitrary first-order atoms, possibly functional • Unifying two arbitrary atoms, possibly both non-grounds

  37. Declarative Programming Formal Software Specification Logic Programming Automated Reasoning Intelligent Databases Formal Logic Theory Logic Programming: a Versatile Metaphor

  38. Logic Programming: Key Ideas

  39. Logic programming vision • Single language with logic-based declarative semantics that is: • A Turing-complete, general purpose programming language • A versatile, expressive knowledge representation language to support deduction and other reasoning services useful for intelligent agents (abduction, induction, constraint solving, belief revision, belief update, inheritance, planning) • Data definition, query and update language for databases with built-in inference capabilities • "One tool solves all" philosophy: • Any computation = resolution + unification + search • Programming = declaring logical axioms (Horn clauses) • Running the program = query about theorems provable from declared axioms • Algorithmic design entirely avoided (single, built-in control structure) • Same language for formal specification (modeling) and implementation • Same language for model checking and code testing

  40. Prolog • First and still most widely used logic programming language • Falls short to fulfill the vision in many respect: • Many imperative constructs with no logical declarative semantics • No commercial deductive database available • Most other logic programming languages both: • Extend Prolog • Fulfill better one aspect of the logic programming vision • In the 80s, huge Japanese project tried to entirely rebuild all of computing from ground up using logic programming as hardware basis

  41. * Pure Prolog Term arg predicate Symbol clauses Definite Query +connective =  Definite Clause +connective =  Numerical Symbol c11 (...,Xk1,...) :- p11(...,Xi1,...), ... , pm1(...,Xj1,...). ... c1n (...,Xkn,...) :- p1n(...,Xin,...), ... , pmn(...,Xjn,...). Definite Logic Program +connective =  Pure Prolog: abstract syntax arg * 0..1 * Pure Prolog Atom * body head Functional Term Function-Free Term functor Variable parent(al,jim)  parent(jim,joe)  anc(A,D)  parent(A,D)  anc(A,D)  parent(A,P)  anc(P,D)

  42. 0..1 body head * Full Prolog Query +connective =  Full Prologl Clause +connective =  Prolog Literal +connective = naf Full Prolog Atom Full Prolog Program +connective =  Full Prolog arg * arg Prolog Literal Full Prolog Term * Functional Term predicate Function-Free Term functor Symbol Built-in Symbol User-Defined Symbol Variable Built-in Imperative Symbol Built-in Logical Symbol • Semantics of full Prolog: • Cannot be purely logic-based • Must integrate algorithmic ones Numerical Symbol Meta-Programming Predicate Symbol I/O Predicate Symbol Search Customization Predicate Symbol Program Update Predicate Symbol

  43. Pure Prolog program declarative formal semantics • Declarative, denotational, intentional: • Clark’s transformation to CFOL formula • First-order formula semantically equivalent to program • Declarative, denotational, extentional, model-theoretic: • Least Herbrand Model • Intersection of all Herbrand Models • Conjunction of all ground formulas that are deductive consequences of program

  44. Classical First-Order Predicate Logic: NoUnique Name Assumption (UNA): two distinct symbols can potentially be paraphrases to denote the same domain entity Open-World Assumption (OWA): If KB |≠ Q but KB |≠ Q , the truth value of Q is considered unknown Ex: KB: true  core(ai)  true  core(se)  core(C)  offered(C,T)  true  offered(mda,fall) Q: true  offered(mda,spring) OWA necessary for monotonic, deductively sound reasoning: If KB |= T then A, KB  A |= T Logic Programming: UNA: two distinct symbols necessarily denote two distinct domain entities Closed-World Assumption (CWA): If KB |≠ Q but KB |≠ Q , the truth value of Q is considered false Ex: ?- offered(mda,spring) fail CWA is a logically unsound form of negatively abductive reasoning CWA makes reasoning inherently non-monotonic as one can have:KB |= T but KB  A |≠ Tif the proof KB |= T included steps assuming A false by CWA Motivation: intuitive, representational economy, consistent w/ databases CFOL x Prolog Semantic Assumptions

  45. Transform Pure Prolog Program P into semantically equivalent CFOL formula comp(P) Same answer query set derived from P (abductively) than from FP (deductively) Example P:core(se). core(ai). offered(mda,fall). offered(C,T) :- core(C). ?- offered(mda,spring) no ?- Naive semantics naive(P):C,T true  core(ai)  true  core(se)  true  offered(mda,fall)  core(C)  offered(C,T) naive(P) |≠ offered(mda,spring) Clark’s completion semantics comp(P): C,T,C1,T1 (core(C1)  (C1=ai C1=se)) (offered(C1,T1)  (C1=mda  T1=fall)  (C,T (C1=C T1=T core(C)))) (ai=se)  (ai=mda)  (ai=fall)  (se=fall)  (se=mda)  (mda=fall)Fp |= offered(mda,spring) Clark’s completion semantics

  46. Clark’s transformation • Axiomatizes closed-world and unique name assumptions in CFOL • Starts from naive Horn formula semantics of pure Prolog program • Partitions program in clause sets, each one defining one predicate (i.e., group together clauses with same predicate c(t1, ..., tn) as conclusion) • Replaces each such set by a logical equivalence • One side of this equivalence contains c(X1, ..., Xn) where X1, ..., Xn are fresh universally quantified variables • The other side contains a disjunction of conjunctions, one for each original clause • Each conjunction is either of the form: • Xi = ci ... Xj = ci, if the original clause is a ground fact • Yi ... Yj Xi = Yi ...  Xj = Yj p1( ...)  ...  pn( ... ) if the original clause is a rule with body p1( ...)  ...  pn( ... ) containing variables Yi ... Yj • Joins all resulting equivalences in a conjunction • Adds conjunction of the form (ci = cj) for all possible pairs (ci,cj) of constant symbols in pure Prolog program

  47. SLD Resolution • SLD resolution (Linear resolution with Selection function for Definite logic programs): • Joint use of goal-driven set of support and input resolution heuristics • Always pick last proven theorem clause with next untried axiom clause • Always questions last pick even if unrelated to failure that triggered backtracking • A form of goal-driven backward chaining of Horn clauses seen as deductive rules • Prolog uses special case of SLD resolution where: • Axiom clauses tried in top to bottom program writing order • Atoms to unify in the two picked clauses: • Conclusion of selected axiom clause • Next untried premise of last proven theorem clause in left to right program writing order (goal) • Unification without occur-check • Generates proof tree in top-down, depth-first manner • Failure triggers systematic, chronological backtracking: • Try next alternative for last selection even if clearly unrelated to failure • Reprocess from scratch new occurrences of sub-goals previously proven true or false • Simple, intuitive, space-efficient, time-inefficient, potentially non-terminating (incomplete)

  48. Refutation proof principle: To prove KB |= F Prove logically equivalent: (KB  F) |= True In turn logically equivalent to: (KB   F) |= False (american(P)  weapon(W)  nation(N)  hostile(N)  sells(P,N,W)  criminal(P)) //1  (T  owns(nono,m1)) //2a  (T  missile(m1)) //2b  (owns(nono,W)  missile(W) sells(west,nono,W)) //3  (T  american(west)) //4  (T  nation(nono)) //5  (T  enemy(nono,america)) //6  (missile(W)  weapon(W)) //7  (enemy(N,america) hostile(N)) //8  (T  nation(america)) //9  (criminal(west)  F) //0 Refutation Resolution Proof Example 1. Solve 0 w/ 1 unifying P/west:american(west)  weapon(W)  nation(N) hostile(N)  sells(west,N,W)  F //10 2. Solve 10 w/ 4:weapon(W)  nation(N)  hostile(N) sells(west,N,W)  F //11 3. Solve 11 w/ 7: missile(W)  nation(N)  hostile(N) sells(west,N,W)  F //12 4. Solve 12 w/ 2b unifying W/m1:nation(N)  hostile(N)  sells(west,N,m1)  F //13 5. Solve 13 w/ 5 unifying N/nono:hostile(nono)  sells(west,nono,m1)  F //14 6. Solve 14 w/ 8 unifying N/nono:enemy(nono,america)  sells(west,nono,m1)  F //15 7. Solve 15 w/ 6: sells(west,nono,m1)  F //16 8. Solve 16 w/ 3 unifying W/m1: owns(nono,m1)  missile(m1)  F //17 9. Solve 17 with 2a: missile(m1)  F //18 10. Solve 18 with 2b: F

  49. SLD resolution example criminal(west)? criminal(P) american(P) weapon(W) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(W) enemy(N,america) owns(nono,W) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

  50. SLD resolution example criminal(west)? criminal(west) american(P) weapon(W) nation(N) hostile(N) sells(P,N,W) sells(west,nono,W) missile(W) enemy(N,america) owns(nono,W) american(west) missile(m1) nation(nono) enermy(nono,america) owns(nono,m1) nation(america)

More Related