3.4 Accepting a Decision
3.4.1 On the Deactivation of Rules in A SPIC +
Before we get to our actual goal (accepting a decision), we need to define a general operation on ASPIC+ knowledge bases that will be required later: Enforcing a set of
arguments, which in turn relies on the operation of deactivating a defeasible rule r. To enforce a set of arguments means to make it part of the grounded extension of an argument graph, and to deactivate a rule means to make it unavailable for reasoning in
3.4. Accepting a Decision 82 accepted arguments (any arguments that use r defeated by an attacker whose conclusion is ¬hri). Both operations will be defined only in terms of additional rules that are added to the knowledge base. They do not require the deletion of any knowledge. Enforcement has been studied for abstract argument graphs [65, 66, 67, 68]. However, no prior work exists on enforcement in the context of instantiated arguments, such as with ASPIC+.
As an example, if a rule r1 expresses the assumption that all birds can fly (r1=
bird(X ) ⇒ fly(X )) then r1 could be deactivated by adding the literal l = ¬hr1i to
the knowledge base. The effect of l is that every argument which uses r1 is attacked
asymmetrically by the argument [¬hr1i]. Of course, r1 could also be attacked in a
specific context only: r2 = penguin(X ) ⇒ ¬hr1i.2 In this section we are interested
in a generic approach to deactivation, such as l. In contrast, rules such as r2 require
domain-specific knowledge and can therefore not be the result of a generic deactivation that can be applied to any possible rule.
Deactivation of rules and enforcement of arguments are highly relevant for engi- neering design. Since design processes are iterative, it is common to revisit previous decisions when assumptions or external requirements have changed. In such cases it is important to keep a record of the reasoning behind the original (changed) decision, in order to prevent repeating the same mistakes, and for auditing purposes. Therefore, the processes analysed in the next chapter have the property that while their underlying knowledge bases grow monotonically, their sets of acceptable arguments do not. This non-monotonicity requires us to override – that is, to make unavailable – rules without actually removing them from the knowledge base.
Our proposal for deactivation and enforcement consists of two functions, which we will define in this section: enforce and deactivate. enforce relies on the more fun- damental operation, deactivate. If a rule r is deactivated then any argument that uses it is attacked asymmetrically (by an argument with conclusion ¬hri) and thus excluded from any preferred extension.
In order to deactivate a rule r in ASPIC+, the deactivate operation defined below (Definition 47) adds a rule r0= ⇒ ¬hri with empty antecedent. Because r0is itself a
2With either of l and r
2, the argument using r1is attacked by the grounded extension of the graph, so
¬fly(X) is sceptically acceptable. This is different from the classical penguin-fly example, where the two conclusions fly(X ) and ¬fly(X ) each have a credulously acceptable argument.
3.4. Accepting a Decision 83 rule, it can be deactivated (and r re-activated) with another rule r00= ⇒ ¬hr0i, resulting in a chain of arguments in the corresponding argument graph. The chain acts as a record of repeated de- and re-activations of r.
In other words, to enable a rule r, we need to “disable” all arguments whose con- clusion is ¬hri. By this definition, to activate a rule r is to un-deactivate its name hri. Note that this does not guarantee the availability of r for arguments, it only means if an argument uses r then it will not be defeated by default.
In this section we will find a correct definition of deactivate in several iterations, by considering various candidates.
3.4.1.1
Naive Approach
The simplest definition of deactivate(r, KB) would be to add the literal ¬hri to the rules in KB:
deactivate1(r, KB) = KB ∪ ({¬hri}, /0)
This will allow us to generate an argument for ¬hri which asymmetrically attacks any argument that uses r, effectively deactivating r. However, there are two disadvantages to this approach:
1. deactivate1 cannot be reversed easily (through adding more knowledge). We could add another literal hri to the knowledge base, but that would lead to a sym- metric attack between it and the argument for ¬hri (assuming the contrariness function behaves like classical negation), so any argument that uses r would be acceptable in some preferred extensions and rejected in others, so its acceptabil- ity would not be exactly the same as before applying deactivate.
2. deactivate1 implictly assumes that there are no arguments with conclusions hri or ¬hri in KB (because if there were, either the new argument would be defeated, or it would be engaged in a symmetric attack, so it would potentially be only cred- ulously acceptable). Ideally the approach should work without any assumptions about KB.
Example 26. To demonstrate why deactivate1 is not an adequate definition, consider theASPIC+ knowledge base KB1= (R1,K1) withR1= {r1}, r1= a ⇒ b andK1=
3.4. Accepting a Decision 84
a1 a2 a3 a4
Figure 3.5: Argument graph for Example 26
R0
1=R1. The argument graph of KB01contains four arguments:
a1= [a]
a2= [a1; a ⇒ b; b]
a3= [¬hr1i]
a4= [hr1i]
As shown in Figure 3.5, a3 attacks a2 and a4. a4 attacks a3. Therefore there are
two preferred extensions, {a1, a2, a4} and {a1, a3}. So the rule r1 is still used in a
credulously acceptable argument (a2) anddeactivate1 did not work as intended.
3.4.1.2
Improvement
The first problem of deactivate1 is irreversibility. More precisely, the problem is that the reversal of deactivate1 would produce a symmetric attack, since arguments can be attacked asymmetrically only on their rules and the argument for ¬hri does not use any rules, since ¬hri is a fact in KB0. This means that any definition of deactivate should only add rules to the knowlege base, not facts. This is what deactivate2 does:
deactivate2(r, KB) = KB ∪ {⇒ ¬hri}
In order to reverse the effect of deactivate2, we could add another rule ⇒ ¬h⇒ ¬hrii, which creates a defender of all arguments that use r. This solves the first issue, but the second one still remains, in addition to a new problem:
1. deactivate2 can be reversed by adding a rule ⇒ ¬h⇒ ¬hrii as described, but what if r is to be de-activated again after that? Simply applying deactivate2 again is not enough, since the rule it creates is already part of the knowledge base and it therefore has no effect at all.
2. The second problem remains: deactivate2 implictly assumes that neither ⇒ ¬hri nor ⇒ ¬h⇒ ¬hrii can be derived from KB.
3.4. Accepting a Decision 85 We are getting closer to a solution, since problem 1 is now a special case of problem 2.
3.4.1.3
Final Definition
The discussion of deactivate2 indicated that the real definition of deactivate has to add a new rule whose content depends on the argument graph of KB. This leads to the following approach for deactivating a rule:
1. Let r0= ⇒ ¬hri3
2. Add r0to the knowledge base
3. For each credulously acceptable attacker a ∈ A of the argument [; r0; ¬hri]: (a) Deactivate topRule(a)
4. Repeat until no more rules are added.
Definition 47 is a straightforward translation of this recipe, except for step 4, which is realised by recursion. deactivate delegates all work to deactivate0, which we will define first:
Definition 46. Let r be a rule and let A be a set of ASPIC+-arguments.
deactivate0(r, A) = {r0} ∪ [
a∈attackers(b,A)
deactivate0(topRule(a), A \ {a})
with r0=⇒ ¬hri, and b = [; r0; ¬hri].
In Definition 46, the variables have the following intuitive meaning: r is the rule to be deactivated by introducing a new argument b, A is the set of arguments with potential attackers of b, r0 is the deactivating rule that enables b, and A0 contains all arguments in A except the “offending” one, a (this guarantees termination as the recursive call is made with a strictly smaller set than A). An example of deactivate0 can be found on page 87 (Example 29).
You may have noticed that the function topRule, which we used in the definition of deactivate0, is only defined for arguments that have a top rule, and undefined for literal arguments such as [a] (cf. its definition on page 30). This is the reason why we only
3rand r0stand for rules, not for rule names. If we want to refer to them in definitions we need to use
3.4. Accepting a Decision 86 consider knowledge bases without literals in this thesis (see discussion on page 32). All literals are represented by defeasible rules of the form ⇒ a, and instead of atomic arguments [a] we have arguments [⇒ a].
With the previous definitions in place, deactivate itself is relatively simple: Definition 47 (Deactivate). Let r be a rule and let KB be an ASPIC+ knowledge base.
deactivate(r, KB) = KB ∪ deactivate0(r, arguments(KB))
By this definition of deactivate (Definition 47), all acceptable attackers of r are themselves attacked (through deactivation of their top rule). The recursion ensures that all leaves of the dialectical tree for each “user” of r are attacked.
Example 27. We begin with a simple example. Consider the argumentation system KB1= {r1, ⇒ a, ⇒ b, ⇒ c} where there is only one rule with non-empty antecedent,
r1= a ⇒ d. Then KB2= deactivate(r1, KB1) = KB1∪ {r0} where r0=⇒ ¬hr1i. The
argument graph of KB2 contains five arguments, a1= [⇒ a], a2= [⇒ b], a3= [⇒ c], a4= [a1; r1⇒ d] and a5= [; ⇒ ¬hr1i; ¬hr1i]. a5attacks a4asymmetrically so the only
preferred extension is{a1, a2, a3, a5} which coincides with the grounded extension. Example 28. An example with multiple preferred extensions, KB2 = {r1, r2, r3, ⇒ a}
with r1= a ⇒ b, r2= a ⇒ ¬b and r3= b ⇒ c.
The arguments for KB2are
a= [⇒ a] b= [a; a ⇒ b; b] c= [a; a ⇒ ¬b; ¬b] d= [b; b ⇒ d; b]
with attacks as in Figure 3.6 (left) on p 87. Dashed lines indicate sub-argument re- lations (transitive sub-arguments may be inferred, for example a is a sub-argument of d). The graph on the left is of KB2 and the graph on the right is of KB02 =
3.4. Accepting a Decision 87 a b c d a b c d e
Figure 3.6: Argument graphs for Example 28.
a1 a2
a3 a4
Figure 3.7: Argument graph for Example 29.
There are two preferred extensions: E1= {a, b, d} and E2= {a, c}. In E2, rule r2
holds and in E1it does not hold.
After deactivating rule r2 with KB02= deactivate(r2, KB2), we get the argument
graph shown in Figure 3.6 on the right. It contains all of KB2’s arguments plus a new
one, e with
e= [; ⇒ ¬hr2i; ¬hr2i]
Argument e attacks c and thus makes rule r2 unusable in any accepted arguments. The preferred extension of KB02’s argument graph now conincides with its grounded extension and contains the arguments a, b, d and e.
Example 29. This example demonstrates how deactivate traverses all counter- arguments, counter-counter arguments and so forth for each user of r1(each argument that uses r1). The original knowledge base (before applyingdeactivate) contained a defeasible rule with empty antecedent,⇒ a, and two rules with non-empty antecedents:
r1= a ⇒ b
r2=⇒ ¬h⇒ ¬hr1ii
If we compute deactivate(r1, KB), then a new rule r3 =⇒ ¬hr1i will be added, dis-
abling r1. However, rule r2 (equal to ⇒ ¬hr3i) which is already in the knowledge
3.4. Accepting a Decision 88 a1
a2 a3 a4
a5
Figure 3.8: Argument graph for Example 29, part II.
why the definition of deactivate contains a recursive clause. Figure 3.7 shows the resulting graph, after applying deactivate(r1, KB). The arguments are a1 = [⇒ a], a2= [a1; r1; b], a3= [; r2; ¬hr3i] and a4= [; r3; ¬hr1i]. Argument a4was introduced by
thedeactivate2 operation, but it is defeated by a3. This is the reason why deactivate needs to examine the resulting argument graph again.
Therefore,deactivate(r1, KB) also contains the knowledge added by deactivate(r2, KB).
The final result ofdeactivate(r1, KB) is the following set of arguments:
a1= [⇒ a] a2= [a1; r1; b]
a3= [; ⇒ ¬h⇒ ¬hr1ii; ¬h⇒ ¬hr1ii] = [; r2; ¬hr3i]
a4= [; ⇒ ¬hr1i; ¬hr1i] = [; r3; ¬hr1i]
a5= [; ⇒ ¬h⇒ ¬h⇒ ¬hr1iii; ¬h⇒ ¬h⇒ ¬hr1iii]
And attacks a5→ a3→ a4→ a2. The grounded extension consists of a5, a4and a1. The
graph is shown in Figure 3.8.
We conclude this example with a detailed description of how deactivate(r1, KB)
is computed. Let R0= deactivate0(r1, arguments(KB)), so deactivate(r1, KB) = KB ∪
KB0. Figure 3.9 on page 89 shows the computation ofdeactivate0step by step.