Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Incremental Computation of Warranted Arguments in Dynamic Defeasible Argumentation: The Rule Addition Case Gianvincenzo Alfano 1 , Sergio Greco 1 , Francesco Parisi 1 , Gerardo Ignacio Simari 2 , Guillermo Ricardo Simari 2 1 Department of Informatics, Modeling, Electronics and System Engineering University of Calabria, Italy { g.alfano, greco, fparisi } @dimes.unical.it 2 Departamento de Ciencias e Ing. de la Computación Universidad Nacional del Sur (UNS) Instituto de Ciencias e Ing. de la Computación (ICIC UNS − CONICET) Argentina { gis,grs } @cs.uns.edu.ar 33 rd ACM/SIGAPP Symposium On Applied Computing Track on Knowledge Representation and Reasoning April 9-13, 2018 Pau, France
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Motivation Dynamic Structured Argumentation A general way for representing arguments and relationships (defeats) between them It allows representing dialogues, making decisions, and handling inconsistency and uncertainty Several kinds of Argumentation Frameworks (e.g. Abstract Argumentation, Structured Argumentation ) A well-known formalism for structured argumentation is DeLP: De feasible L ogic P rogramming Argumentation frameworks are often dynamic (change over time) as a consequence of the fact that argumentation is inherently dynamic (change mind/opinion, new available knowledge) We devise an incremental technique for computing conclusions in structured argumentation frameworks (avoiding wasted effort due to recomputation from scratch)
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Motivation DeLP We focus on De feasible L ogic P rogramming, a formalism that combines results of Logic Programming and Defeasible Argumentation. DeLP is a knowledge representation language, where defeasible and non-defeasible rules can be expressed. The language has two different negations: classical negation, used for representing contradictory knowledge and negation as failure, used for representing incomplete information. A defeasible argumentation inference mechanism for warranting the conclusions that are entailed.
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Outline Introduction 1 Motivation Background 2 Defeasible Logic Programming Incremental Computation 3 Updates Dealing with Irrelevant Updates Dealing with Relevant Updates Our Technique Implementation & Experiments 4 Conclusions and future work 5
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming A DeLP Program DeLP considers two kinds of program rules: defeasible rules to represent tentative information, and strict rules used to represent strict knowledge. Example Consider the DeLP-program P 1 = (Π 1 , ∆ 1 ) , where: � w , t , z , ( p ← t ) � Π 1 = � ( ∼ a − ≺ y ) , ( y − ≺ x ) , ( x − ≺ z ) , ( ∼ x − ≺ p , t ) � ∆ 1 = ( a − ≺ w , y ) , ( ∼ w − ≺ t ) , ( y − ≺ p ) , ( x − ≺ p ) The (non-contradictory) set of literals that can be derived from Π 1 is { w , t , z , p } . However, both a and ∼ a can be derived from P 1 using the following sets of rules and facts: ( a − ≺ w , y ) , ( y − ≺ p ) , ( p ← t ) , ( t ) and ( ∼ a − ≺ y ) , ( y − ≺ p ) , ( p ← t ) , ( t ) , respectively.
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Argument Given a DeLP program P = (Π , ∆) and a literal α , we say that �A , α � is an argument for α if A is a set of defeasible rules of ∆ such that: (i) there is a derivation for α from Π ∪ A , (ii) the set Π ∪ A is not contradictory, and (iii) A is minimal (i.e., there is no proper subset A ′ of A satisfying both (i) and (ii)). Example Given P 1 , we have the following arguments (among others): �A 1 , ∼ a � = �{ ( ∼ a − ≺ y ) , ( y − ≺ x ) , ( x − ≺ z ) } , ∼ a � �A 2 , ∼ a � = �{ ( ∼ a − ≺ y ) , ( y − ≺ p ) } , ∼ a � �A 3 , a � = �{ ( a − ≺ w , y ) , ( y − ≺ p ) , } , a � �A 4 , ∼ x � = �{ ( ∼ x − ≺ t , p ) } , ∼ x � �A 5 , x � = �{ ( x − ≺ p ) } , x �
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Argument Given a DeLP program P = (Π , ∆) and a literal α , we say that �A , α � is an argument for α if A is a set of defeasible rules of ∆ such that: (i) there is a derivation for α from Π ∪ A , (ii) the set Π ∪ A is not contradictory, and (iii) A is minimal (i.e., there is no proper subset A ′ of A satisfying both (i) and (ii)). Example (An argument for ∼ a built from the previous program) Given P 1 , we have the following arguments (among others): �A 1 , ∼ a � = �{ ( ∼ a − ≺ y ) , ( y − ≺ x ) , ( x − ≺ z ) } , ∼ a �
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Argumentation Line A sequence of arguments obtained from a DeLP program, where each element of the sequence is a defeater of its predecessor. Example (Argumentation Line) α 2 α 3 α 0 α 1 A 0 A 2 A 3 A 1 Example (An argumentation line from the previous program) Given P , an argumentation line is the following: [ A 1 , A 3 ]
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Dialectical Process Example (Dialectical Tree) A 0 Given an argument A for a literal L , the dialectical tree A 1 contains all acceptable argumentation lines that start A 2 B 2 with that argument. A 3 B 3 C 3 It allows to determine the status for a given argument. A 4 C 4 C 5
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Dialectical Process: Marking Procedure Example (Dialectical Tree) U All leaves are marked as U = Undefeated D = Defeated Undefeated . D U D An argument in the tree is marked as Defeated if and only if it has at least a child D U U marked as Undefeated . U D U
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Defeasible Logic Programming Status of literals The status of literals allow us to determine the conclusions we can draw from a DeLP-program. S P : Lit → { IN , OUT , UNDECIDED , UNKNOWN } assigning a status to each literal w.r.t. P as follows: S P ( α ) = IN if there exists a (marked) dialectical tree whose root α is Undefeated S P ( α ) = OUT if S P ( ∼ α ) = IN S P ( α ) = UNDECIDED if neither S P ( α ) = IN nor S P ( α ) = OUT S P ( α ) = UNKNOWN if α �∈ Lit P , i.e., α is not in the language of the program Example (Arguments from the previous program) Given P , then S P ( t ) = IN , S P ( ∼ w ) = OUT , S P ( a ) = UNDECIDED .
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Outline Introduction 1 Motivation Background 2 Defeasible Logic Programming Incremental Computation 3 Updates Dealing with Irrelevant Updates Dealing with Relevant Updates Our Technique Implementation & Experiments 4 Conclusions and future work 5
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Updates Adding a rule to a DeLP program An update consists of modifying a DeLP-program P into a new DeLP-program ′ by adding a strict or a defeasible rule. In particular, P ′ is as follows: P If r is a strict rule, then if (Π ∪ r ) is not contradictory, then P ′ = ((Π ∪ r ) , ∆) otherwise P ′ = P (i.e., the update has no effect if it would yield a contradictory program). If r is a defeasible rule, then P ′ = (Π , (∆ ∪ r )) , that is, adding a defeasible rule is always permitted. Example (Perform r =( a − ≺ x ) on P 1 ) The updated DeLP-program P ′ 1 = (Π ′ 1 , ∆ ′ 1 ) , is as follows: Π ′ � � 1 = Π 1 = w , t , z , ( p ← t ) � ( ∼ a − � ≺ y ) , ( y − ≺ x ) , ( x − ≺ z ) , ( ∼ x − ≺ p , t ) ∆ ′ 1 = ∆ 1 = ∪ { ( a − ≺ x ) } ( a − ≺ w , y ) , ( ∼ w − ≺ t ) , ( y − ≺ p ) , ( x − ≺ p )
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Updates Question After performing an update the conclusion that can be derived may change: the status of a is IN (was UNDECIDED ) after performing the update r = ( y ← t ) in our example. Should we recompute the status of literals from scratch?
Introduction Background Incremental Computation Implementation & Experiments Conclusions and future work Updates Overview of our incremental approach Two main steps. 1) First, we check if the update is irrelevant (the status of all literals are preserved). In such a case we simply return the initial status S P . 2) To efficiently deal with relevant updates, we identify the subset of literals whose status needs to be recomputed after performing an update, and only recompute their status.
Recommend
More recommend