Composition and Interoperation of Rules Enrico Pontelli and Tran - PowerPoint PPT Presentation

Composition and Interoperation of Rules Enrico Pontelli and Tran Cao Son Chitta Baral Department of Computer Science Computer Science and Engineering New Mexico State University Arizona State University Department of Computer Science

Overview • Motivations • Proposed Approach • Formal Syntax and Semantics – Pure Language – Handling Side Effects • Implementation • Conclusions Department of Computer Science

Motivations • Several RuleML languages – distinct syntax – distinct reasoning mechanisms • The needs of an agent: – Reasoning within a single knowledge base B • agent needs to interact with the inference engine http://www.ruleml.org/modularization/#Model relevant for the RuleML flavor of B – Reasoning across knowledge bases B 1 ,…, B n • agent’s interaction with different inference engines • ability to scope reasoning to a specific B i • composition of results from different inference engines Department of Computer Science

Proposed Approach • Logic Programming as a common core – many RuleML languages can be converted to different flavors of logic programming • Develop a Logic Programming system that allows integration of modules belonging to different flavors of logic programming – standard Prolog – Prolog with updates – Answer Set Programming – Well-founded Model Programming – Fuzzy Logic Programming – … Department of Computer Science

Proposed Approach • Technology – ASP-Prolog • framework that provides a semantically well-founded integration of Prolog and ASP – modules and module hierarchy (import/export lists) – PiLLoW (CIAO Library) to access RuleML documents – Definite Clause Grammars (DCGs) for conversion of RuleML to logic programming Department of Computer Science

Architecture CORE FRAMEWORK ASP (nafdatalog) ASP PiLLoW Prolog Prolog (hornlog) W4 Compiler Semantic RuleML CLP Documents Web CLP … ASP-Prolog Program CLIPS Compilation (ECA) Phase CLIPS Modules Jess Department of Computer Science

Language Syntax • Result of RuleML compilation < F , Π , V > Signature • Π = Π u ∪ Π d (user-defined and built-ins) – • built-ins: assert, retract, model – Literals • p(t 1 ,…,t n ) (atom) • not p(t 1 ,…,t n ) (naf-atom) • t: p(t 1 ,…,t n ) (qualified atom) • datalog – Rules: • ground datalog • pure Prolog ← A B , ..., B • impure Prolog 1 n • … Ξ -rules ( Ξ = datalog, ground datalog, pure Prolog, …) – Department of Computer Science

Language Syntax • Module Structure – Module M • name(M) (ground term) • import(M) (list of ground terms – names of other modules) • export(M) (list of predicates) • rules(M) (set of Ξ -rules) – Program P = {M t1 , …, M tn } • name(M ti ) = t i – graph(P) = ({t1,…,tn}, E) • (x,y) ∈ E iff x ∈ import(y) • acyclic Department of Computer Science

Pure Language: Semantics M 10 M 7 M 8 M 9 M 1 M 2 M 4 M 5 M 6 Department of Computer Science

Pure Language: Semantics M 10 M 7 M 8 M 9 M 1 M 2 M 4 M 5 M 6 Based Semantics (NAT) Department of Computer Science

Pure Language: Semantics τ: H P → 2 BP (model naming) • • t 1 , …, t n topological sort of graph(P) • NAT(T) ⊆ 2 BP “natural” semantics for a program T – T does not contain qualified atoms – e.g., • T is a datalog program, NAT(T) is the least Herbrand model of T • T is a naf-datalog program, NAT(T) is the set of answer sets of T M τ P (M ti ) ⊆ 2 BP semantics of module M ti • – MR(M,A 1 ,…,A k ) model reduct of module M w.r.t. A 1 ,…,A k • replace each t i :model(t) with true (false) if τ (t) ∈ A i • replace each t i :p with true (false) if p ∈ S for each S ∈ A i (otherwise) • replace each t:p with true (false) if p ∈ τ (t) (p ∉τ (t)) M τ P (M ti ) = NAT(MR(M ti , M τ P (Μ t1 ) ,…, M τ P (Μ ti-1 ))) Department of Computer Science

Impure Language • Presence of assert/retract towards other modules – for simplicity, performed in module t n , impure Prolog module • Operational Semantics State: (G, θ , P) – Transition: (G, θ , P) ⇒ (G’, θ ’, P’) – select atom A from G, H ← Body in M tn • G’ = (G \ {A} ∪ Body) mgu(A,H) – θ ’ = θ º mgu(A,H) – – P’ = P select t i :A from G and H ∈ S for all S ∈ M τ P (M ti ) • – G’ = G \ {A} θ ’ = θ º mgu(A,H) – – P’ = P select t:A from G and H ∈ τ (t) • – G’ = G \ {A} θ ’ = θ º mgu(A,H) – – P’ = P select t i :model(t) from G and τ (t) ∈ M τ P (M ti ) • – G’ = G \ {t i :model(t)} θ ’ = θ – – P’=P • select t i :assert(r)/t i :retract(r) from G – G’ = G \ { t i :assert(r)/t i :retract(r)} θ ’ = θ – P’ = P \ {M ti } ∪ {M ti ∪ {r}} [P’ = P \ {M ti } ∪ {M ti \ {r}} ] – Department of Computer Science

Handling Non-Logical Modules • ECA rules – simplified view: the model M τ P (M ti ) of an ECA module is the content of the working memory at a stable state – ASP/Prolog facts imported as CLIPS facts in working memory – Content of the working memory publicized as logic facts Department of Computer Science

Implementation ASP-Prolog Module Preprocessor Load updated CIAO Prolog Prolog Prolog Modules Modules Goals interface modules ASP Modules model classes Answers interface ECA modules Modules CLIPS Modules Department of Computer Science

Implementation • Main module (module t n ) CIAO Prolog (top-level) • Prolog Modules – updated to access the newly created CIAO Interfaces of other modules • ASP Modules – compiled to • interface module: exports predicates that are defined in the module and built-ins (e.g., assert, retract) • model class: a CIAO Class whose objects represent individual answer sets (i.e., sets of ground facts) • interface invokes Smodels each time the module is modified; Smodels output converted to instances of the model class • ECA Modules – compiled to CLIPS modules – Prolog interface: • translates working memory content to Prolog facts • implements assert/retract (addition/removal of elements in the working memory of CLIPS) • based on CIAO Java interface Department of Computer Science

Implementation: ECA Rules Module 1 export p p(a) :- ... P rolog CLIP S P rogram P rogram import p export q assert p(a) (defrule “...” ?f < - (p ?x) = > (retract ?f) (assert (q ?x))) getfacts import q ... :- ..., q, ... E CA Module Module k Department of Computer Science

Implementation • Some additional considerations – Prolog to be used to • access RuleML documents (via PiLLoW HTTP interface) • use PiLLoW to convert XML to terms • Definite Clause Grammars to parse terms and translate to Prolog/ASP/ECA modules Department of Computer Science

Conclusion and Future Work • CIAO Prolog (+ASP, +CLIPS) as a core framework for integration of distinct RuleML flavors • Logic Programming as a reasoning engine • Flexibility of Prolog – allows to handle conversion to/from RuleML within Prolog – allows implementation of sophisticated reasoning mechanisms, e.g., • preferences • qualitative reasoning Department of Computer Science

Conclusion and Future Work • Complete implementation – currently the Prolog+ASP core is completed – URL: http://www.cs.nmsu.edu/~okhatib/asp_prolog.html • Extend the scope of interoperation – Extend module structure capabilities • inheritance • macros – RIFRAF Department of Computer Science