Design Goals

Argkit consists of several modules, bundled together under the collective argumentation heading. This page outlines the design goals for each of the current and foreseen modules. As ArgKit is a software library, it's global design goals are correctness and extensibility, so the module design goals are written based on the questions "what should it do?" and "how is it anticipated to be extensible?".

Dungine

The goal of the Dungine module is to compute Dung acceptability semantics over an arbitrary directed graph where the nodes are arguments and the edges are defeats. It will use argument games to compute the semantics. Unlike other argumentation engines it should be agnostic as to the source of the argument graph.

It is anticipated that Dungine should be extensible in the following ways:

  1. It should be possible to use different sources of arguments and defeats
  2. It should be possible for users to add new semantics to the library, by writing their own reasoners.

Defeasible Knowledge Base

Although Dungine isn't restricted to a particular argument source, ArgKit needs to provide a useful one. This defeasible knowledge base, DKb, should provide an expressive source of defeating arguments. DKb will use a prolog-like syntax where each clause (a rule or a fact) can be qualified and each rule can be named. It should be possible to use any qualifier as long as it's values form a partial ordering, for instance real valued qualifiers (perhaps representing probabilities) could be used. Similarly, integer qualifiers or an ordered enumeration of symbolic qualifiers could be used. Defeats would then be defined based on the overall qualifiers of conflicting compound arguments.

It is anticipated that DKb should be extensible in the following ways:

  1. users should be able to add new qualifiers
  2. users can build their own strategies for valuating a compound argument

AIFlib

The AIFlib should provide a mechanism for persisting and recovering an evaluated argument graph. The underlying model for this mechanism will be based on the Argument Interchange Format (AIF). To be persistable, an argument source must be associated with an AIF framework that extends the core abstract AIF framework with rules that validate

  1. allowed classes of nodes and edges in an argument graph
  2. allowed content of nodes
  3. cardinality of links between different classes of nodes.

The module should be designed so that multiple backends can be used (e.g. RDF files, databases, XML files), but RDF will be used as the default.

Decision

It should be possible to collect different arguments for a claim, and build a system that understands that multiple arguments for the same claim have more force than one of those arguments on it's own. An easy way to use this notion is with the concept of a decision which has candidates and a commitment rule. The candidates can be claims of arguments, and multiple arguments with the same claim (or it's negation) can be thought of as arguments for and against the claim respectively. The Decision module should be extendible in the areas of:

  1. commitment rules and
  2. the mechanism for eliciting arguments associated with a candidate.

Closing Note

This page still has too much jargon and references to academic concepts (argument games, AIF). If there is a demand, more explanation can be added.