Introduction

Gorgias is a general argumentation framework that combines the ideas of preference reasoning and abduction in a way that preserves the benefits of both of them. It can form the basis for reasoning about adaptable preference policies in the face of incomplete information from dynamic and evolving environments. For instance, in buying a car, one may prefer certain features over others; in scheduling, meeting some deadlines may be more important than meeting others; in legal reasoning, laws are subject to higher principles, like lex superior or lex posterior, which are themselves subject to "higher order" principles.

For a detailed discussion of the concepts in this tutorial, see:

Getting Started

An SWI-Prolog (SWI-Prolog) installation is needed as a requirement for Gorgias. Get the latest tarball of Gorgias from our download section and untar it into the final installation location on your computer. You can start using Gorgias by checking out the examples that come bundled with the distribution.

You can write your own domain descriptions by adding the following lines on the top of a file stored in the examples directory: 


        :- compile('../lib/gorgias.pl').
        :- compile('../ext/lpwnf.pl').
The first line is loading the system itself while the second line is loading a collection of rules that define a qualification relation between arguments that is exploited by the attacking relation to encode the relative strength of arguments. We discuss the qualification relation further at the end of this tutorial. In the sequel, we describe the language for representing various domains of discourse.

Representing Knowledge

We normally use prolog terms formed by predicate symbols to denote rules, conflicts and preferences between rules. The syntax of such descriptions is given by labelled rules of the form: 

    rule(Label, Head, Body)
where, the Head is a literal, the Body is a list of literals, and the label is a compound term composed of a rule name and selected variables from the Head and Body. Negative literals are terms of the form neg(L). For example, 

    rule(r1(X), fly(X), [bird(X)]).
    rule(r2(X), neg(fly(X)), [penguin(X)]).
denotes that something flies if it is a bird. Priority relations are again described using the rule syntax given above together with the special predicate prefer(Label1, Label2) in the head of the rule which means that the rule with label Label1 has higher priority than the rule with label Label2 if the literals in the body hold. The role of the priority relation is to encode locally the relative strength of rules in the theory, typically between contradictory rules. For example, the rule 

    rule(pr1(X), prefer(r2(X), r1(X)), []).
taken from the tweety example below denotes that r2(X) is a stronger statement than r1(X), i.e. provided that something is both a bird and a penguin the statement that "it does not fly" will prevail.

Finally, an abducible literal L is specified using the special predicate abducible/2. For example, 


    abducible(regular_customer(_), []).
Note that an abducible declaration may contain preconditions specifying under what circumstances the literal is an abducible predicate. For the purpose of this tutorial, we will restrict ourselves to abducible declarations without any preconditions.

Finally, the statement conflict(Label1,Label2) indicates that the rules with labels Label1 and Label2 are conflicting. In many cases conflict(Label1,Label2) will be true iff heads of the rules with labels Label1 and Label2 are contrary literals, but other rules can also be declared as conflicting by the designer of the domain description.

Computing Argumentation and Answering Queries

In general, the construction of a solution for a given query can be done incrementally, starting from a basic/initial argument, by adding to the initial argument suitable defences for it. We are mostly concentrated on the computation of a special class of arguments, namely admissible arguments. Intuitively, an argument is admissible if it defends itself against each attack. Note that an argument that attacks itself cannot be admissible, because there is no attack against the empty set.

The computation of an admissible argument is an interleaving of two phases: In the first phase a goal is reduced to a closed set that proves the goal. Then, this initial argument is expanded with suitable defences for each attack against the initial set. However, after the growing of the initial argument new conflicts might have arised and thus the system repeats the whole process until there is no defence for an attack against the basic argument (i.e. failure to find an admissible set) or until there are no more attacks (i.e. succesful derivation of an admissible argument).

Queries are submitted to the system as follows: 


    prove(Goals, Delta).
where, Goals is a list of positive (or negative) literals while Delta is an admissible argument for the given query. For example, an admissible argument Delta for the query prove([neg(fly(tweety))],Delta) of the tweety problem discussed in the sequel is Delta = [f2, r2(tweety)].

Static Preferences

The Tweety Problem

The canonical Tweety problem -- infering that Tweety can fly from the facts that Tweety is a bird and that birds typically fly; and retracting that conclusion upon discovering that Tweety is a penguin -- is formulated as follows: 

    rule(r1(X), fly(X), [bird(X)]).
    rule(r2(X), neg(fly(X)), [penguin(X)]).

    rule(f1, bird(tweety), []).
    rule(f2, penguin(tweety), []).

    rule(pr1(X), prefer(r2(X), r1(X)), []).
The last rule in the description above states that rule r2(X) is stronger than r1(X), i.e. X cannot fly if it is both a bird and a penguin. Such preference rules are called static since their truth value does not depend on any defeasible preconditions while preference rules with at least one defeasible literal in their body are called dynamic. We have shown that an admissible set for the query prove([neg(fly(tweety))],Delta) is Delta = [f2, r2(tweety)]. It is easy to verify that prove([fly(tweety)],Delta) has no solution. Feel free to comment out (using % in the beginning of the line) the preference rule pr1. You'll notice that the system generates a solution (i.e. an admissible set) for both sets.

Dynamic Preferences

In the sequel, we study an example with dynamic preferences, i.e. preferences that are subject to some conditions.

Inheritance with Exceptions

Now let us consider an inheritance hierarchy of the form depicted in the figures below.

An inheritance hierarchy consists of an acyclic graph representing the proper subclass relation between classes and a collection of defaults from these subclasses to properties of objects. Dotted arrows denote properties of objects and the dashed arrow denotes the possible addition of a subclass relation between a and d that is discussed in the end of this section. The domain description encoding the hierarchy from the figure in the left consists of domain dependent axioms: 


    rule(f1, subclass(a,b), []).
    rule(f2, subclass(c,b), []).
    rule(f3, subclass(d,c), []).
    rule(f4, is_in(x1,a),   []).
    rule(f5, is_in(x2,c),   []).
    rule(f6, is_in(x2,c),   []).


    rule(d1(X), has(X,p),      [is_in(X,b)]).
    rule(d2(X), neg(has(X,p)), [is_in(X, c)]).

    rule(pr1, prefer(d2(X), d1(X)), []).
where has(X,P) stands for "element X has property P") and the domain independent axioms: 


    % General properties of subclass and is_in

    rule(r1(C0,C2), subclass(C0,C2), [C0 \= C1, C1 \= C2, C0 \= C2, subclass(C0,C1), subclass(C1,C2)]).
    rule(r2(X,C1), is_in(X,C1),      [subclass(C0,C1), is_in(X,C0)]).


    % Closed world assumptions for simple hierarchies

    rule(d3(X,C), neg(is_in(X, C)),   []).
    rule(d4(A,B), neg(subclass(A,B)), []).
The first two rules represent general properties of subclass and is_in. The last two rules express the closed world assumptions for simple hierarchies. It is easy to check that the domain is consistent and that the logic program generates admissible arguments for has(x1,p) and neg(has(x2,p)).

Higher-Order Preferences

Consider the program in the previous section extended by 

    rule(f7, subclass(d,a), []).
to represent the fact that d is also a subclass of a and 

    rule(d4, prefer(d1(X), d2(X)), [is_in(X,a)]).
to express that instances of d have the property p. Now, both d1(X) < d2(X) and d2(X) < d1(X) can be proved for x3 and thus both has(x3,p) and neg(has(x3,p)) are consequences of an admissible set. One way to resolve this conflict is to rewrite the rules d3(X) and d4(X) as: 

    rule(d3'(X), prefer(d2(X), d1(X)), [is_in(X,c), neg(is_in(X,a))]).
    rule(d4'(X), prefer(d1(X), d2(X)), [is_in(X,a), neg(is_in(X,c))]).
However, these rewritten rules do not represent the specification of the given domain in a natural way since such a practice would lead into a combinatorial explosion on the number of literals in the body of the priority rules and thus degrading the high-intentionality of the language. In contrast Gorgias, can accept rules stating priorities over priorities, i.e. higher-order priorities. For example, the following rule 

    rule(d5(X), prefer(d4(X), d3(X)), [is_in(X,a)]).
states that an instance of d has the property p beside the fact that d is also a subclass of c. Another well-known example where higher-order priorities could be exploited is the following legal reasoning scenario [Gordon, 1993].
A person wants to find out if her security interest in a certain ship is perfected. She currently has possession of the ship. According to the "Uniform Commercial Code" (UCC) a security interest in goods may be perfected by taking possession of the collateral. However, there is a federal law called the "Ship Mortgage Act" (SMA) according to which a security interest in a ship may only be perfected by filing a financing statement. Such a statement has not been filed. Now the question is whether the UCC or the SMA takes precedence in this case. There are two known legal principles for resolving conflicts of this kind. The principle of "Lex Posterior" gives precedence to newer laws. In our case the UCC is newer than the SMA. On the other hand, in the principle of "Lex Superior" gives precedence to laws supported by the higher authority. In our case the SMA has higher authority since it is a federal law.
In legal reasoning, laws are subject to higher principles, like lex superior or lex posterior, which are themselves subject to "higher order" principles. A straightforward representation of the stated problem above is shown below: 

    rule(ucc, perfected,      [possession]).
    rule(sma, neg(perfected), [ship, neg(finstatement)]).

    rule(f1, possession,        []).
    rule(f2, ship,              []).
    rule(f3, neg(finstatement), []).
    rule(f4, newer(ucc,sma),    []).
    rule(f5, federal_law(sma),  []).
    rule(f6, state_law(ucc),    []).

    rule(lex_posterior(X,Y), prefer(X,Y), [newer(X,Y)]). 
    rule(lex_superior(X,Y),  prefer(Y,X), [state_law(X),federal_law(Y)]).

    rule(prpr, prefer(lex_superior(X,Y),lex_posterior(X,Y)), []).
It is easy to check that an admissible argument for neg(perfected) in the given domain is D = [lex_superior(ucc, sma), f5, f6, f3, f2, sma].

The last rule in the description is a higher-order preference rule, exactly because it states a preference/priority over the priority rules lex_superior(X,Y) and lex_posterior(X,Y).

Eventhough, both lex_superior(X,Y) and lex_posterior(X,Y) are subject to a number of preconditions, they are not dynamic since those preconditions are not defeasible.

The Qualification Relation

Argumentation presupposes disagreement, which is captured in this framework by the notion of conflict. Conflicting arguments may coexist in a knowledge base and thus the attacking relation employs a qualification relation during argumentation that encodes the relative strength of arguments that conclude a predicate with different negation status.

One simple example of a qualification relation is "prefer monotonic rules." Intuitively, "prefer monotonic rules" sets the truth value of a predicate to the one suggested by a monotonic rule rather than a default rule.

The qualification relation consists of rules of the form 


    % attacks0(?QR, ?LT, +Culprit, +Argument, ?CounterArgument)
where QR is the name of a concrete instance of a qualification relation, LT is the level type that the relation may be applied (either 'A' or 'D' for attack and defence level, respectively), Culprit is a rule label or assumption in the given Argument that forms the basis on which we're gonna construct the CounterArgument. For instance, 

    attacks0('GEN', _, ass(L), _, CA) :-

        complement(L, NL),

        rule(Sig, NL, Body),

        resolve(Body, Resolvent),

        CA = [Sig|Resolvent].
denotes the qualification relation GEN that may be applied either in an attack level or a defence level, i.e. no constraints on the level type, and it constructs a counterargument CA provided that the given argument contains an assumption (the culprit in our case) ass(L).

Gorgias can be extended with domain-specific qualification relations. This topic will be covered in a future revision of this document.

More