A SPIC + Conventions

As we mentioned before, we will adopt some conventions for ASPIC+ knowledge bases

in this thesis. The first set of conventions aims to streamline the presentation of our ideas by simplifying definitions and proofs, and the second set of conventions enables us to reason about arguments about rules, by restricting the arguments we can poten- tially form.

At the same time, all knowledge bases considered in this thesis are valid ASPIC+ knowledge bases, so all related work on ASPIC+ applies to our system without adjust- ments. However, not all of our results transfer to general ASPIC+ systems.

In the following paragraphs, remember that ASPIC+ systems are four-tuples (L ,·,Rs∪Rd, ≤) and ASPIC+ knowledge bases are pairs (K ,≤0) withR = Rd∪Rs,

≤ a partial order ofR_d,K = Kn∪Kp∪Kawith ≤0a partial order ofK \ Kn.

2.3.2.1

Simplifications

As this thesis is about modeling human argumentation, we regard all knowledge to be defeasible and consequently all our ASPIC+ rules will be defeasible. Concretely, we require that Rs = /0 (no strict rules). This means that R = Rd. We also make

no assumptions about the ordering of rules inR, so we define ≤ to contain only the minimum information necessary to make it a partial order - that is, ≤ only contains pairs of rules (r, r) so that it satisfies the property of reflexivity: ≤= {(r, r0) ∈R_d×R_d| r = r0}.

Regarding knowledge bases, we assume there are no ASPIC+-assumptions (in the

set Ka). Whenever the behaviour of assumptions (literals that can be disproved) is

required, we will use a defeasible rule with empty antecedent instead. For example, we write ⇒ bird(Tweety) to express the assumption that Tweety is a bird. This con- vention allows us to introduce attacks on assumptions that always succeed, through a literal ¬h⇒ bird(Tweety)i, which results in an asymmetric attack on the argument [⇒ bird(Tweety)]. We also assume there are no ASPIC+-axioms. As a result, we

always setKn=Ka= /0.

The definition of ≤0 follows the familiar pattern of containing only the minimum of information required for it to be a partial order: ≤0= {(a, a0) ∈Kp×Kp| a = a0}.

2.3. Aspic+ 33 attacks (so they do not become defeats and do not appear in the argument graph of the ASPIC+ system). ≤ and ≤0therefore solve the same problem as Dung’s extension

semantics – both decide which attacks hold and which attacks are to be rejected. By restricting the two relations we ensure that all attacks are evaluated within the argument graph that is generated from an ASPIC+ system, and not at the stage where attacks are turned into defeats inside ASPIC+ (cf Definition 11).

Argument graphs in ASPIC+ arise from a combination of a general ASPIC+ system (L ,·,Rs∪Rd, ≤) with concrete knowledge bases (K ,≤0). Due to the the restrictions

we make, we can drop ≤ and ≤0from these definitions because they are directly deter- mined byK and Rs. In addition, we assume that  (the argument ordering required

to decide which attacks are defeats, Definition 11) is defined in the same, minimal way, which allows us to elide it too (because in this setting, all ASPIC+-attacks are ASPIC+-

defeats). Further, we will assume the logical languageL to consist only of atoms, so all inferences will be made via rules inR. L is therefore just a set of symbols, and we will not mention it explicitly in our definitions and examples. The same goes for the naming function h·i. As a result we can drastically simplify our presentation: Instead of specifying a four-tuple and a pair, we only need to give a single component,R (de- feasible rules) explicitly. We will therefore adopt the notation KB =R to specify both the ASPIC+ system (L ,·,R,≤) and the knowledge base (K ,≤0) withK = /0, where KBstands for “knowledge base”. Since KB is a set we can use ⊆ to determine whether one knowledge base contains another one, and ∪ to describe the union of two knowl- edge bases. We will use the function argGraph(KB) to refer to the argument graph of a knowledge base KB.

2.3.2.2

Other Restrictions

In chapters 3 and 4 we will develop a model of decision making in which decisions made at an earlier stage in the process can impact decisions made at a later stage. Conversely, decisions at a later stage can override decisions made earlier. In order to ensure that our definitions have the desired properties for overriding knowledge, we will assume that all ASPIC+ knowledge bases meet the following two conditions: Condition 1: No Unused Rules In a given knowledge base KB =R, for every rule r∈R, there exists at least one argument a ∈ args(KB) such that topRule(a) = r.

2.3. Aspic+ 34 Condition 2: Injective Rule Labels The function h·i is injective, so each rule is as- signed a different name.

We are now going to define a number of common functions that operate on objects in ASPIC+. These functions will make it easier to refer to specific parts of an argument

or a set of arguments. We start with the attackers function, which restricts a set of arguments A to those that attack a given argument a.

Definition 13 (Attackers). For all ASPIC+ arguments a, and A⊆A : attackers(a,A) = {b ∈ A | b attacks a}

We also use the function attacks(A) to return all pairs of arguments (a, b) ∈ A × A such that a attacks b.

In the context of argumentation systems, specifically for ASPIC+, a knowledge

base KB infers a literal l, short KB ` l, if there exists an argument with conclusion l that is acceptable under a given semantics, for example grounded or preferred. The inference relation is therefore parameterised over the semantics, and we use an index pr to indicate preferred semantics and gr for grounded semantics. The following definition is based on Definition 14 in [41]:

Definition 14 (ASPIC+ Inference). Let KB be an ASPIC+ knowledge base and let l∈ L . Let s ∈ {gr,pr}. KB s-infers l, short KB `sl, if and only if there exists an extension

E∈ Σs(argGraph(KB)) such that a ∈ E.

In addition to the conventions on ASPIC+ systems and knowledge bases just dis- cussed, we will also use the following syntax for arguments, which is easy to read and conveys all the information contained in an argument.

To refer to arguments we use variables a, b, . . .. When talking about the structure of an argument a we write a = [l] if a is a literal argument (Definition 9 case 1) and we write a = [b1, . . . , bn; r; c] if a is the application of a rule r with sub-arguments b1to

b_n and conclusion c. In both cases, the conclusion is immediately visible (either l or c) and in the second case both sub-arguments and the rule are included. The following example demonstrates our syntax conventions.

2.3. Aspic+ 35 ¬c. KB gives rise to the following arguments. args(KB) = {a₁, . . . , a₅} with

a₁= [⇒ a] a₂= [⇒ b]

a₃= [⇒ c] a₄= [a1; r1; d]

a₅= [a4, a2; r2; ¬c]

We getattacks(args(KB)) = {(a₅, a3), (a3, a5)}. In other words, a5rebuts a3and vice

versa.