GORGIAS : Applying argumentation

Abstract

This paper presents the past and present efforts of developing real-life applications of argumentation with the Gorgias preference-based structured argumentation framework of Logic Programming with Priorities. Since its free availability on the web in 2003, the Gorgias system has been used by different groups in a variety of real-life applications in areas such as medical support, network security, business computing, ambient intelligence and, recently, in the area of cognitive personal assistants. We briefly review the Gorgias framework and its past applications and present an emerging general methodological approach for developing “decision making” applications of argumentation. This approach allows the development of real world applications directly from their high-level requirements expressed in the language of the application without the need for familiarity with the underlying technical details of argumentation. A new tool, called Gorgias-B, supports this high-level development of applications and automatically generates the underlying argumentation theory in Gorgias code. The paper also reports on ongoing real-life applications in two domains: an eye-clinic assistant for first level support, and systems for patient data access and data sharing agreements according to the relevant legislation and contracts or policies of the several stakeholders involved. The proposed approach is quite general for this type of applications of argumentation and, thus, it can be used with any preference-based argumentation framework.

1. Introduction

Over the last two decades there has been an ever increasing interest in applying argumentation to analyze and solve practical problems in the area of Artificial Intelligence (AI). The natural link of argumentation to human reasoning (see, e.g., [35]) makes Computational Argumentation an appropriate framework for applications in AI. This suitability of argumentation applies to problems with strict specifications, requiring expert (e.g., scientific) reasoning, as well as to problems of human-like AI, where the reasoning required is closer to that of common sense used by people when they tackle their everyday tasks. We, therefore, see applications of argumentation over a wide spectrum of problems, ranging from applications focusing on the analysis of debates (e.g., debates on on-line social interaction settings [16,29,52]) to problems where a more formal structure of argumentation needs to be captured computationally (e.g., in automating legislation [7,45]). There are also several systems of argumentation, such as CaSAPI [14], DeLP [15], TOAST [46] and Gorgias [21], that provide tool support for studying various aspects of computational argumentation and its application.

A wide class of applications of argumentation concerns decision problems in dynamic and incomplete, or uncertain, environments. These include problems of diagnosis, e.g., in the medical domain [10,31] or in other domains such as home networks [12], legal problems [6], or recommendation problems, e.g., medical treatment recommendation systems [37]. More generally, some practical works in the category of “decision making” applications include e-commerce applications [18], negotiating supply strategies [56], making credit assignments [41], managing waste-water discharges [2], deciding about an automatic freight process [8], improving the performance of transport systems in rural areas [54], emergency rescue [57], aggregating clinical evidence [19], smarter electricity [32] and delivering clinical decision support services1

¹

http://www.openclinical.org/argumentation.html

 [13].

Nevertheless, there is lack of works that would help the systematic development of argumentation software for real world applications. This paper aims to address this gap by proposing a simple yet powerful methodological approach that can facilitate the systematic development of (a certain class of) applications of argumentation. The goal is to allow experts in their application domains to use argumentation based methods and tools for modeling their decision making problems with no or little need for technical knowledge on formal argumentation.

More generally, in today’s era of human-like AI and Cognitive Computing, there are three main challenges to developing applications, which are particularly well served by an approach based on argumentation and which our approach aims to tackle. Firstly, the acquisition and elicitation of the application requirements needs to be carried out at a high-level akin to the natural cognitive level of the domain experts, or personal users, for whom the application software is built. Secondly, these systems need to be incrementally developed and improved or adapted to new and changing requirements in a highly modular way, possibly through a continuous learning process that accompanies their development. Finally, systems need to be accountable, with their decisions or recommendations being explainable to people, a feature that is now required by law in the European Union. In effect, the systems need to be able to argue, in a natural human-like way, about the suitability of their operation with respect to the high-level requirements or guidelines provided by the application owners.

Our approach to developing such applications of argumentation has emerged out of the experience from several real-life applications of argumentation based on the preference-based structured argumentation framework of Logic Programming with Priorities [11,21,22] and its Gorgias2

²

http://www.cs.ucy.ac.cy/~nkd/gorgias/

implementation. These include applications in medical support systems, network security, business computing, ambient intelligence, pervasive services and, recently, cognitive personal assistants.

This approach is based on the consideration of application scenarios and the provision, by the domain expert, or the application owner and/or user, of statements of preference on the possible solutions within these scenarios. The expert, or owner, is guided to analyze the conflicts in the application scenarios, or combinations of these, and to consider possible refinements of the scenarios that could resolve or mitigate the conflict. The important characteristic of this approach is that it can be carried out at a high level familiar to the domain expert or application owner. It abstracts away from the technical details of argumentation through the possibility of automatically transforming the high-level specification into an argumentation theory and executable [11,21,22] Gorgias code. As such, our approach aims to address, at least partly, the three challenges for today’s AI systems cataloged above.

The paper briefly reviews the preference-based argumentation framework of Gorgias together with various real-life applications of argumentation based on this framework. The methodological approach for developing applications of argumentation, that has emerged through this variety of applications, is presented and illustrated through some of these applications and other examples. We show how a new tool, called Gorgias-B, employing a novel human-machine interface, supports the proposed approach and provides an automatic translation of the high-level scenario-based preference specification into a corresponding argumentation theory and Gorgias software code. The paper also reports on an ongoing real-life application of an eye-clinic assistant for providing first level support at the clinic by ascertaining the severity of the case of a new patient case and thus helping in prioritizing patient appointments. Similarly, we report on the current development of data access and sharing applications for patient medical records where multiple policy requirements from legislation and other stakeholders need to be integrated together to regulate the access to information.

In section two we present the general class of application problems for argumentation that we will consider in this paper. We describe the overall structure of these problems and illustrate this with an example. Then, in section three, we show how these problems can be captured within the argumentation framework of Gorgias. In section four we discuss the various real-life applications developed so far with Gorgias. Subsequently, in section five, we present the general methodological approach for applications of argumentation, along with the Gorgias-B tool developed for supporting the proposed approach. Section six highlights the current challenges for Gorgias by providing an insight of the real-life applications under development and section seven concludes.

2. Application problems for argumentation

A wide class of application problems which can be captured using argumentation are in essence decision problems. Argumentation is particularly suitable when the application environment is incomplete and dynamic. The incompleteness and volatility of information typically mean that there is insufficient information to have a strict decision policy and, hence, the flexibility of argumentation provides a way to account for and manage the possible alternative decisions that can be taken.

In this paper we will consider applications which can be formulated in the form of a decision problem whose language of description is composed of the following parts:

OPTIONS:

This is the set of the various results of the decision making problem. Options characterize the solutions to the application problem. In practice, options are typically actions and hence the problem is to decide what course of action to take, e.g., to decide on a user’s level of access to sensitive data. In some cases, options are explanations that help to classify a situation, e.g., to match the symptoms of a patient with a set of possible diseases. In many of these cases the explanation is just an intermediate step towards achieving the overall objective to decide on a course of action, such as what therapy to recommend.

SCENARIO INFORMATION:

A set of relations that are used to (partially) describe the possible states of the application environment called scenarios. These relations capture the various types of information that we expect to be available from the application environment when we are asked to apply the decision making process to solve particular instances of the problem. This information can be sensory information readily available or it may be information that can be actively sought from the environment. In this case the application system may need to prompt the environment for this information. This practical consideration separates the sensory information into two types: directly observable and hypothetical with the latter requiring a decision to actively seek it.

SCENARIO-Based PREFERENCES:

A set of tuples $⟨\mathit{S};\mathit{O}⟩$ of (partial) scenarios, S, together with a corresponding preferred subset, O, of options in the scenario S. This part of the description of an application captures the criteria or guidelines under which the solutions of the problem should be sought. They can be seen as high-level requirements to help find a satisfactory solution in any particular circumstance of the problem given by some partial description of the application environment. Note that the scenarios, S, that appear in these statements refer to a minimal set of information about the application environment that is sufficient for the domain expert to be able to express some preference amongst the possible options. As we will see below it is very useful to group these scenarios in hierarchies of increasing specificity.

It is important to note that this “language scheme” for specifying decision problems allows the application domain experts to formulate and describe their application at a high and non-technical level, solely within their familiar application language. The domain expert does not need to be aware of the technical details of the underlying argumentation framework in which the problem will eventually be expressed. Hence, the Scenario-based Preferences (SP), capture at a high level the required behaviour of any system for solving the problem. Depending on the application, these are expressions of expert knowledge, e.g., in a medical support application the expert (doctor or other medical personnel) provides the set of preferred possible causes, or actions to be taken, for various patient scenarios. On the other hand, for human-like AI applications, such as cognitive personal assistants, the scenario-based preferences come from personal preferences of the human user. These can be in the form of high-level guidelines for the assistant, such as for example, the preference for good quality food or the avoidance of red meat, in the context of building on-line shopping personal assistants.

2.1. Scenarios and scenario-based preferences

In expressing the scenario and scenario-based preference specification of an application problem there are two important notions that help us to relate and organize these requirements. Firstly, given a scenario S, we can expand this with further, non-empty, scenario information C, to obtain a new scenario ${\mathit{S}}^{\prime }$ , ${\mathit{S}}^{\prime }=\mathit{S}\cup \mathit{C}$ . ${\mathit{S}}^{\prime }$ will be called a refinement of S, as ${\mathit{S}}^{\prime }$ provides a more refined description than that of S. Successive scenario refinements result in a hierarchy of scenarios starting from an initial scenario S. We will denote such a hierarchy by ${\mathit{S}}^{\mathit{k}}$ ( $\mathit{k}=1\mathrm{,}2\mathrm{,}\dots \mathrm{,}\mathit{n}$ ) where ${\mathit{S}}^1=\mathit{S}$ and ${\mathit{S}}^{\mathit{k}}={\mathit{S}}^{\mathit{k}-1}\cup {\mathit{C}}^{\mathit{k}}$ ( $\mathit{k}\mathrm{>}0$ ), where ${\mathit{C}}^{\mathit{k}}$ is a non-empty set of scenario information disjoint from ${\mathit{S}}^{\mathit{k}-1}$ , referred to as the context at the kth level of the hierarchy. Scenarios can be identified by a subscript, e.g., ${\mathit{S}}_{\mathit{\alpha }}$ , where α can be any symbol, normally one that abbreviates the scenario description. Given two (initial) scenarios ${\mathit{S}}_{\mathit{\alpha }}$ and ${\mathit{S}}_{\mathit{\beta }}$ , their combination is a new scenario obtained simply by their set union.3

³

Clearly, the combination of two (different) scenarios also forms a refinement of each scenario by the other where the non-common part of the scenarios forms the context of the refinement.

We will denote a combination by ${\mathit{S}}_{\mathit{\alpha }\mathrm{,}\mathit{\beta }}$ , i.e., ${\mathit{S}}_{\mathit{\alpha }\mathrm{,}\mathit{\beta }}={\mathit{S}}_{\mathit{\alpha }}\cup {\mathit{S}}_{\mathit{\beta }}$ .

Refinements and combinations of scenarios have an effect on the corresponding scenario-based preferences that refer to the scenarios involved. Given two scenario-based preferences $\mathit{SP}=\mathrm{(}\mathit{S};\mathit{O}\mathrm{)}$ and ${\mathit{SP}}^{\prime }=\mathrm{(}{\mathit{S}}^{\prime };{\mathit{O}}^{\prime }\mathrm{)}$ such that ${\mathit{S}}^{\prime }$ is a refinement of S, i.e., ${\mathit{S}}^{\prime }\supset \mathit{S}$ , we say that ${\mathit{SP}}^{\prime }$ is a refinement of $\mathit{SP}$ . When in addition ${\mathit{O}}^{\prime }\subseteq \mathit{O}$ , we will say that ${\mathit{SP}}^{\prime }$ is a focusing of $\mathit{SP}$ , as ${\mathit{SP}}^{\prime }$ focuses, or sharpens, the preference statement of $\mathit{SP}$ . Similarly, a hierarchy of scenarios, ${\mathit{S}}^{\mathit{k}}$ , induces a hierarchy ${\mathit{SP}}^{\mathit{k}}=\mathrm{(}{\mathit{S}}^{\mathit{k}};{\mathit{O}}^{\mathit{k}}\mathrm{)}$ on the set of scenario-based preferences. When ${\mathit{SP}}^{\mathit{k}}$ is a focusing of ${\mathit{SP}}^{\mathit{k}-1}$ for any $\mathit{k}\mathrm{>}1$ , i.e., when $\mathit{O}\supseteq {\mathit{O}}^1\supseteq {\mathit{O}}^2\supseteq \cdots \supseteq {\mathit{O}}^{\mathit{n}}$ we say that ${\mathit{SP}}^{\mathit{k}}$ is a focusing hierarchy of scenario-based preferences.

Note that when a refinement, ${\mathit{SP}}^{\prime }=\mathrm{(}{\mathit{S}}^{\prime };{\mathit{O}}^{\prime }\mathrm{)}$ , of a given scenario-based preference, $\mathit{SP}=\mathrm{(}\mathit{S};\mathit{O}\mathrm{)}$ , is not also a focusing of $\mathit{SP}$ , the set ${\mathit{O}}^{\prime }$ of preferred options in ${\mathit{SP}}^{\prime }$ can be completely different: ${\mathit{O}}^{\prime }$ can contain options not in O and can possibly be disjoint from O. This is an indication of a change of context in the preference statements when we move from S to ${\mathit{S}}^{\prime }$ . A typical case of this, is the change from a default context in general situations described by S to exceptional or specialized contexts when some additional specific information is considered in a refined scenario ${\mathit{S}}^{\prime }$ . Similarly, when we are considering the combination of two scenarios the preferred options in the combined scenario can be any subset of options that is independent from the sets of the preferred options in the individual scenarios. Hence this information of the preferred options in the combined scenario must be obtained independently from the same source (application expert/owner/user) that provides the scenario-based preferences.

Finally, we note that when we refine or combine scenarios we need to know if the resulting scenarios are plausible, i.e., they indeed describe possible cases of the application environment, or in other words, that they are not inconsistent. Again this information of plausibility of scenarios needs to be provided independently by the source of the application requirements.

2.2. An illustrative example

In order to illustrate the high-level description of an application problem let us consider a simple example where we want to capture the guidelines of a human user for an on-line shopping personal assistant. The set of options in this problem is to buy, or not, various products in a supermarket. For simplicity, let us assume that this set contains the following options (and their negations): $$\begin{array}{l}\mathit{OPTIONS}=\{\mathit{buy}\mathrm{(}\mathit{lamb}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{fish}\mathrm{)}\}.\end{array}$$

The application problem is to decide which buy options to select. For ease of presentation, we assume that we only buy one type of these foods when shopping, i.e., that these options are mutually exclusive. The user has informed us that all these options are enabled under the minimal scenario information of “main shopping” for the week (denoted here by $\mathit{main}\text{\_}\mathit{shopping}$ ). This can be captured by a basic or initial scenario-based preference statement as follows:4

⁴

As defined above, the general notation that we will use to denote scenarios (and correspondingly scenario-based preferences) is ${\mathit{S}}_{\mathit{y}}^{\mathit{x}}$ , where y is an optional abbreviated scenario description symbol and x stands for the refinement level.

$$\begin{array}{ll}\hfill {\mathit{SP}}_{\mathit{m}}^1& =⟨{\mathit{S}}_{\mathit{m}}^1=\{\mathit{main}\text{\_}\mathit{shopping}\};\\ \hfill & {\mathit{O}}_{\mathit{m}}^1=\{\mathit{buy}\mathrm{(}\mathit{lamb}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{fish}\mathrm{)}\}⟩.\end{array}$$

We will say that these options are enabled or available in the basic scenario ${\mathit{S}}_{\mathit{m}}^1$ . The user can then express preferences on these enabled options depending on different further scenario information that is indeed sufficient for a meaningful preference to be expressed. For example, the user can prefer the cheaper options, expressing the preference for the typically cheaper foods of pork and chicken: $$\begin{array}{ll}\hfill {\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}}^2& =⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2={\mathit{S}}_{\mathit{m}}^1\cup \{\mathit{cheap}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}\mathit{cheap}\mathrm{(}\mathit{chicken}\mathrm{)}\};\\ \hfill & {\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{c}}^2=\{\mathit{buy}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\}⟩.\end{array}$$

The user may have a preference amongst the cheaper options, e.g., a preference for pork in the winter and for chicken in the summer. These additional preferences may be captured in further scenarios, which are refinements of the scenario ${\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2$ , in the same way that ${\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2$ is a refinement of the initial scenario ${\mathit{S}}_{\mathit{m}}^1$ : $$\begin{array}{l}{\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3=⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3={\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2\cup \{\mathit{winter}\};{\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3=\{\mathit{buy}\mathrm{(}\mathit{pork}\mathrm{)}\}⟩\mathrm{,}\\ {\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{s}}^3=⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{s}}^3={\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2\cup \{\mathit{summer}\};{\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{s}}^3=\{\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\}⟩.\end{array}$$

In refinements of scenarios the user is able to focus further her/his preference amongst the preferred options of the parent scenario. Note that given a scenario the user may have different, independent ways to refine the scenario. In our example, the user may have another preference amongst the cheaper options, e.g., for the locally produced foods. Hence we can have a new refined scenario-based preference of: $$\begin{array}{l}\hfill {\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{l}}^3=⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{l}}^3={\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2\cup \{\mathit{local}\mathrm{(}\mathit{chicken}\mathrm{)}\};{\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{l}}^3=\{\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\}⟩\end{array}$$ when the cheap chicken is also produced locally.

When we have different scenarios whose conditions can hold together in the application then we are led to consider combinations of scenarios, i.e., a new scenario made up of the union of the two scenarios. The user typically considers the preferred options amongst the union of the preferred options in the two scenarios. This occurs, for example, when it is possible that different refinements of a scenario occur together, e.g., when in our example both the refinements of $\mathit{winter}$ and $\mathit{local}\mathrm{(}\mathit{chicken}\mathrm{)}$ hold together: $$\begin{array}{ll}\hfill {\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}\mathrm{,}\mathit{l}}^4& =⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}\mathrm{,}\mathit{l}}^4={\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{l}}^3\cup {\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3={\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{c}}^2\cup \{\mathit{winter}\}\cup \{\mathit{local}\mathrm{(}\mathit{chicken}\mathrm{)}\};\\ \hfill & {\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}\mathrm{,}\mathit{l}}^4=\{\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\}⟩\mathrm{,}\end{array}$$ which expresses the preference for the locally produced chicken even in the winter time, where pork is generally preferred amongst the cheap options.

In our example, we have considered so far refinements and combinations of scenarios stemming from the scenario condition of “cheap price”. We could have other scenario conditions on the application environment that are independently sufficient to express a preference. For example, the preference for locally produced foods of the user may be a general preference that applies irrespective of the price. If this is the case this general preference is not captured by the scenario-based preference, ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}\mathrm{,}\mathit{l}}^4$ above, as this applies as a preference only amongst the cheap options and not as an overall preference for locally produced food. If we wanted the later we would have a new scenario-based preference based on a new independent refinement of the initial scenario, ${\mathit{S}}_{\mathit{m}}^1$ : $$\begin{array}{l}{\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{l}}^2=⟨{\mathit{S}}_{\mathit{m}\mathrm{,}\mathit{l}}^2={\mathit{S}}_{\mathit{m}}^1\cup \{\mathit{local}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}\mathit{local}\mathrm{(}\mathit{lamb}\mathrm{)}\};{\mathit{O}}_{\mathit{m}\mathrm{,}\mathit{l}}^2=\{\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}\mathit{buy}\mathrm{(}\mathit{lamb}\mathrm{)}\}⟩\end{array}$$ when only chicken and lamb are locally produced. We would then continue by considering refinements or combinations of this scenario, e.g., its combination with ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}}^2$ or its refinement with the context of winter or summer.

In certain applications, it is possible for the list of preferred options in the new refined or combined scenarios, to contain options that are outside the (union of) options in the “parent” scenario-based preferences. For example, the user prefers lamb for special occasions and chicken when s/he is not feeling well, but when both these hold (i.e., in the combined scenario of a special occasion when s/he is not feeling well) s/he prefers fish. Finally, we note that we can also have “local” preference statements between an option and its negation, e.g, the user may express the preference not to buy fish if it is farmed: $$\begin{array}{l}{\mathit{SP}}_{\mathit{f}\mathit{f}}^1=⟨{\mathit{S}}_{\mathit{f}\mathit{f}}^1=\{\mathit{farm}\mathrm{(}\mathit{fish}\mathrm{)}\};{\mathit{O}}_{\mathit{f}\mathit{f}}^1=\left\{\mathit{not}\mathrm{\right(}\mathit{buy}\mathrm{(}\mathit{fish}\mathrm{)}\mathrm{\left)}\right\}⟩.\end{array}$$ These are “vertical” preferences that apply locally only to the particular option involved.

Some of the scenario information may not be readily available to the shopping assistant at the time of operation, e.g., in our example the user may have expressed a preference for buying lamb or fish when the week contains a special occasion but the information of $\mathit{special}\text{\_}\mathit{occasion}$ may not always be directly available to the assistant. We can then designate such conditions as hypothetical so that the system would be able to perform an action (e.g., prompt the user) to find out about this. For example, while in some week the chicken is on special offer and, hence, cheap, the system selects lamb, after it finds out by asking the user that there is a special occasion in this week.

A principled approach to capture the preference requirements, or guidelines, of an application problem, would involve identifying possible combinations of the scenarios expressed directly by the user, which contain conflicting preferences, and prompting or learning from the user further preferences under such combined scenarios and their refinements. This process can be applied iteratively to consider further combinations with any new scenarios introduced. In Section 5 we will present a general methodological approach for eliciting from the application domain expert, or user, these preference requirements.

3. Applications in the Gorgias argumentation framework

In this section we briefly overview the Gorgias argumentation framework and indicate how application problems can be formulated as an argumentation theory in it.

Gorgias is a structured argumentation framework, where arguments are constructed using a basic argument scheme of Modus Ponens to link a set of premises with the claim, or position, of the argument. An argument, A, is a set of argument rules, denoted by $\mathit{Premises}⊳\mathit{Claim}$ . Such an argument rule links a set of $\mathit{Premises}$ , normally given as facts, with the $\mathit{Claim}$ : we say that the argument rule supports the $\mathit{Claim}$ . In an argument, A, through the successive application of its constituent argument rules, several claims including a “final” claim are derived and hence supported by A. Argument rules have the syntax of Extended Logic Programming, i.e., rules whose conditions and conclusion (claim) are positive or explicit negative atomic statements without the need to use a second form of Negation as Failure in the conditions5

⁵

There are historical reasons for this as the original motivation of presenting the Gorgias argumentation framework in [11] was to give an argumentation formulation for Logic Programming without Negation as Failure.

. The conclusion of an argument rule can be a positive or negative atomic statement.

In the context of the type of applications described in the previous section, the premises are typically given by a set of conditions describing a scenario and the claim is an option. There are cases, however, where the conditions are themselves defeasible. We call them beliefs, and they can be argued for or against, i.e., the claim of an argument can also be a literal on a belief predicate. The distinction, then, between beliefs and options, is that options cannot be premises of arguments whose claim is a belief.

When the claim of an argument is a literal on an option (or belief) predicate, this argument is called an object-level argument. Such object-level arguments can support contradictory claims (e.g., one claim is the other’s negation), in which case these arguments attack each other. The object-level arguments in the framework are supplemented by priority arguments whose purpose is to give a relative strength between arguments. Their role is to tighten the attack relation between arguments and sets of arguments, by allowing an argument to attack another only if it is at least as strong as the argument that it attacks. The priority arguments express a local preference between two arguments. They have the same syntactic form of $\mathit{Premises}⊳\mathit{Claim}$ , but now the $\mathit{Claim}$ is of a special form, ${\mathit{a}}_1\mathrm{>}{\mathit{a}}_2$ , where ${\mathit{a}}_1$ and ${\mathit{a}}_2$ are any two other individual argument rules. Note that ${\mathit{a}}_1$ and ${\mathit{a}}_2$ can themselves be priority argument rules, in which case we say that the argument, P, is a higher-order priority argument expressing the fact that we prefer one priority over another, in the context of the premises of P. Hence, the framework of Gorgias is a preference-based argumentation framework where we can express conditional preferences and higher-order preferences over arguments.

The formulation of an application problem is then given by a Gorgias argumentation theory where the knowledge describing the application is represented in terms of object and priority arguments rules. The dialectic argumentation process to determine the acceptability (i.e., the good quality) of an argument supporting a desirable claim (e.g., an option) occurs between composite arguments. A Composite argument is a (minimal and closed) set of arguments, $\mathrm{\Delta }=\mathrm{(}{\mathit{A}}_1\mathrm{,}{\mathit{A}}_{\mathit{P}}\mathrm{)}$ , where, ${\mathit{A}}_1$ , is a subset of object level argument rules and ${\mathit{A}}_{\mathit{P}}$ is a subset of priority argument rules, chosen from the given argumentation theory. Thus, composite arguments form the set, $\mathit{Args}$ , of (formal) arguments in an abstract argumentation framework, $⟨\mathit{Args}\mathrm{,}\mathit{ATT}⟩$ , corresponding to any given Gorgias argumentation theory.

The attack relation, $\mathit{ATT}$ , between two composite arguments is induced from a notion of strength that the priority arguments give to the arguments that they accompany inside a composite argument. Informally, a composite argument, ${\mathrm{\Delta }}_1$ , attacks another composite argument, ${\mathrm{\Delta }}_2$ , whenever they are in conflict, i.e., they support incompatible claims or are based on incompatible premises, and the arguments in ${\mathrm{\Delta }}_1$ are rendered by the priority arguments that it contains at least as strong as the arguments contained in ${\mathrm{\Delta }}_2$ . In other words, if the priority arguments in ${\mathrm{\Delta }}_2$ render an argument in it preferred over an individual argument in ${\mathrm{\Delta }}_1$ then so do the priority arguments in ${\mathrm{\Delta }}_1$ : a relative weak argument in ${\mathrm{\Delta }}_1$ is balanced by a weak argument in ${\mathrm{\Delta }}_2$ . The precise detail of the definition of this attack relation is not important in this paper and can be found in the papers that introduced Gorgias [11,21].

Once we have such a corresponding abstract argumentation framework, $⟨\mathit{Args}\mathrm{,}\mathit{ATT}⟩$ , we can then use one of the standard definitions of acceptability of arguments to select the acceptable arguments within the Gorgias argumentation theory that captures our application problem. The choice of semantics that is predominantly used in the Gorgias framework, is that of admissible arguments as the acceptable arguments, namely composite arguments that (a) are not self-attacking and (b) attack back all other arguments that attack them. Admissible arguments thus give, through the options that they support, “good” solutions to our problem, i.e., solutions that conform to the guidelines of the problem representation expressed in the argumentation theory. In the special case where there are admissible arguments supporting only one of the possible options of the problem, then this option is regarded as a “best or optimal” solution.

3.1. Illustrative example continued

Let us illustrate the Gorgias argumentation framework and how we can capture in this a problem specification using the example of the on-line shopping assistant (partially) specified above.

The knowledge of the various minimal (possibly empty) set of scenario conditions, ${\mathit{S}}^1$ , in which options are specified as possible ones is represented by object-level arguments, written here in the form6

⁶

Note that in the implementation language of Gorgias these are written as rules with ⊳ replaced by rule implication →.

$\mathit{a}\mathrm{(}\mathit{i}\mathrm{)}={\mathit{S}}^1⊳{\mathit{O}}_{\mathit{i}}$ , for each option ${\mathit{O}}_{\mathit{i}}$ in the subset of preferred options, ${\mathit{O}}^1$ , of a scenario-based preference statement, ${\mathit{SP}}^1=⟨{\mathit{S}}^1;{\mathit{O}}^1⟩$ . Hence, in our example above, with ${\mathit{S}}^1=\{\mathit{main}\text{\_}\mathit{shopping}\}$ , this would give a set of object-level arguments, enabling their corresponding options, as follows: $$\begin{array}{l}\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}=\{\mathit{main}\text{\_}\mathit{shopping}\}⊳\mathit{buy}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}\\ \mathit{a}\mathrm{(}\mathit{lamb}\mathrm{)}=\{\mathit{main}\text{\_}\mathit{shopping}\}⊳\mathit{buy}\mathrm{(}\mathit{lamb}\mathrm{)}\mathrm{,}\\ \mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{main}\text{\_}\mathit{shopping}\}⊳\mathit{buy}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}\\ \mathit{a}\mathrm{(}\mathit{fish}\mathrm{)}=\{\mathit{main}\text{\_}\mathit{shopping}\}⊳\mathit{buy}\mathrm{(}\mathit{fish}\mathrm{)}.\end{array}$$

Given further scenario-based preference statements we can build priority arguments on top of these object-level arguments to capture these statements. For example, ${\mathit{SP}}^2$ in our example that expresses the general preference for the cheap foods would be captured, in the specific case of pork and chicken being cheaper than lamb and fish, by the priority argument rules: $$\begin{array}{l}{\mathit{p}}_{\mathit{c}1}\mathrm{(}\mathit{pork}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{pork}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{lamb}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{c}2}\mathrm{(}\mathit{pork}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{pork}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{fish}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{c}1}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{chicken}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{lamb}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{c}2}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{chicken}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{fish}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{pork}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{cheap}\mathrm{(}\mathit{chicken}\mathrm{)}\}⊳\mathrm{(}\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{)}.\end{array}$$

Note that the last two priority rules capture the fact that the options of pork and chicken in ${\mathit{SP}}^2$ are not comparable, or equally preferred. Then, the further refined scenario-based preferences of ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3$ and ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{s}}^3$ for $\mathit{pork}$ in the winter and $\mathit{chicken}$ in the summer will be represented by the additional higher-level priority argument rules: $$\begin{array}{l}{\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}=\{\mathit{winter}\}⊳\mathrm{(}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{s}}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{summer}\}⊳\mathrm{(}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{)}.\end{array}$$

These higher level priority rules capture the implicit preference of the more specific scenario-based preferences over the more general ones. Similarly, the other refined scenario-based preference, ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{l}}^3$ , for a preference to local products amongst the cheaper foods will be represented by higher-level priority argument rules, such as: $$\begin{array}{l}{\mathit{c}}_{\mathit{l}}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\mathit{local}\mathrm{(}\mathit{chicken}\mathrm{)}\}⊳\mathrm{(}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{)}.\end{array}$$

Then, the more refined scenario-based preference, given by ${\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}\mathrm{,}\mathit{l}}^4$ , which considers the combination of the “seasonal” and “local” refinements and prefers local food, is captured with a yet higher-level priority argument rule: $$\begin{array}{l}\mathit{d}\mathrm{(}\mathit{chicken}\mathrm{)}=\{\}⊳\mathrm{(}{\mathit{c}}_{\mathit{l}}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{>}{\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{)}.\end{array}$$

Therefore, we see that we can develop a systematic translation of scenario-based preferences, where successive refinements of a scenario give priority argument rules at a higher level every time we consider a further refinement in the scenario. Before considering such a general algorithm that transforms hierarchies of scenario-based preferences to Gorgias argumentation theories let us briefly illustrate how the admissibility property of composite arguments is decided in the Gorgias framework.

Consider a current situation – a specific application scenario – where $\mathit{main}\text{\_}\mathit{shopping}$ holds, pork and chicken are cheaper than the other foods (lamb and fish) and it is winter. We can construct the following two composite arguments, whose argument rules apply (or enabled) under the given application scenario, supporting the option to buy pork or chicken respectively: $$\begin{array}{l}{\mathrm{\Delta }}_1=\{\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}1}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}2}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}\}\mathrm{,}\\ {\mathrm{\Delta }}_2=\{\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}1}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}2}\mathrm{(}\mathit{chicken}\mathrm{)}\mathrm{,}{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}\}.\end{array}$$

The priority argument rules that these contain render them stronger than arguments supporting the options to buy lamb or fish. In addition, since there are no priority arguments that are enabled in the current application scenario which can give higher priority to lamb or fish over pork or chicken, the options of lamb and fish are not supported by any relative strong and hence admissible composite argument.

${\mathrm{\Delta }}_1$ and ${\mathrm{\Delta }}_2$ attack each other because they each include a priority rule that makes its arguments relatively stronger than the opposing one, i.e., ${\mathrm{\Delta }}_1$ contains ${\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}$ that makes its argument $\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}$ stronger than the conflicting argument $\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}$ of ${\mathrm{\Delta }}_2$ and vice versa ${\mathrm{\Delta }}_2$ contains ${\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}$ that makes its object-level argument relatively stronger. But ${\mathrm{\Delta }}_1$ can strengthen itself by also incorporating the priority argument rule ${\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}$ which indeed applies in the specific application scenario since $\mathit{winter}$ holds. We thus have a new argument ${\mathrm{\Delta }}_1^{\prime }={\mathrm{\Delta }}_1\cup \{{\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}\}$ which is stronger. To see how this strengthening of ${\mathrm{\Delta }}_1$ comes about we notice that ${\mathrm{\Delta }}_1$ and ${\mathrm{\Delta }}_2$ are in conflict in a second way, namely that ${\mathrm{\Delta }}_1$ supports the preference of $\mathit{a}\mathrm{(}\mathit{pork}\mathrm{)}$ over $\mathit{a}\mathrm{(}\mathit{chicken}\mathrm{)}$ whereas ${\mathrm{\Delta }}_2$ supports the opposite preference. For this conflict, which comes from ${\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}$ and ${\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{chicken}\mathrm{)}$ , the extra priority rule ${\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}$ in ${\mathrm{\Delta }}_1^{\prime }$ gives relative priority to the first one and, hence, ${\mathrm{\Delta }}_2$ is attacked by the subset $\{{\mathit{p}}_{\mathit{c}3}\mathrm{(}\mathit{pork}\mathrm{)}\mathrm{,}{\mathit{c}}_{\mathit{w}}\mathrm{(}\mathit{pork}\mathrm{)}\}$ of argument ${\mathrm{\Delta }}_1^{\prime }$ but ${\mathrm{\Delta }}_2$ cannot attack back, i.e., defend against this attack by ${\mathrm{\Delta }}_1^{\prime }$ . In fact, no composite argument supporting the option $\mathit{chicken}$ can be constructed that attacks back all its attacking arguments and, hence, only the option of pork has admissible arguments rendering it the only decision/solution that can be admitted in the specific application scenario.

3.2. Transforming scenario-based preferences to argumentation theories

An application problem description in terms of scenario-based preferences can be automatically transformed into a Gorgias argumentation theory once its SPs have been arranged in a set of SPs hierarchies. Informally, the algorithm which carries this out maps the lowest level of an SP hierarchy, $⟨{\mathit{S}}^1;{\mathit{O}}^1⟩$ , into object level arguments for each of the options in ${\mathit{O}}^1$ and then higher-level refinements in the SP hierarchy are mapped into priority arguments over the previous level arguments.

The central part of this translation is Algorithm 1 that maps a focusing hierarchy, ${\mathit{SP}}^{\mathit{i}}$ ( $\mathit{i}=1\mathrm{,}2\mathrm{,}\dots \mathrm{,}\mathit{n}$ ), into arguments. Once we set up, for each option o in ${\mathit{O}}^1$ the object level argument: ${\mathit{arg}}_{\mathit{o}}^{{\mathit{SP}}^1}={\mathit{S}}^1⊳\mathit{o}$ , the recursion of this algorithm works to generate the priority arguments at each ith level ( $\mathit{i}=2\mathrm{,}\dots \mathrm{,}\mathit{n}$ ) of the hierarchy in the form: $$\begin{array}{l}{\mathit{arg}}_{\mathit{o}\text{\_}\mathit{over}\text{\_}{\mathit{o}}^{\prime }}^{{\mathit{SP}}^{\mathit{i}}}=\mathrm{(}{\mathit{S}}^{\mathit{i}}-{\mathit{S}}^{\mathit{i}-1}\mathrm{)}⊳\mathrm{(}{\mathit{arg}}_{\mathit{o}\text{\_}\mathit{over}\text{\_}{\mathit{o}}^{\prime }}^{{\mathit{SP}}^{\mathit{i}-1}}\mathrm{>}{\mathit{arg}}_{{\mathit{o}}^{\prime }\text{\_}\mathit{over}\text{\_}\mathit{o}}^{{\mathit{SP}}^{\mathit{i}-1}}\mathrm{)}.\end{array}$$ Note that $\mathrm{(}{\mathit{S}}^{\mathit{i}}-{\mathit{S}}^{\mathit{i}-1}\mathrm{)}$ is the context at the ith level of the hierarchy. The naming, or labeling, of the argument rules used here is ${\mathit{arg}}_{\mathit{o}}^{{\mathit{SP}}^1}$ for the object level rules and ${\mathit{arg}}_{\mathit{o}\text{\_}\mathit{over}\text{\_}{\mathit{o}}^{\prime }}^{{\mathit{SP}}^{\mathit{i}}}$ for the priority rules at each level (with ${\mathit{arg}}_{\mathit{o}}^{{\mathit{SP}}^1}\equiv {\mathit{arg}}_{\mathit{o}\text{\_}\mathit{over}\text{\_}{\mathit{o}}^{\prime }}^{{\mathit{SP}}^1}$ for any $o^{\prime }$ ).

This elaborate indexing of the argument rules is needed when we extend this algorithm to deal with several scenario-based hierarchies, where it is possible for the same scenario to appear in multiple hierarchies. It is also needed when we generalize this central algorithm to non-focusing scenario-based preference hierarchies. Both these extensions are straight forward to carry out but their details are outside the scope of this paper.

Algorithm 1:

Central Algorithm for Argument Generation

Algorithm 1 captures the general meta preference of a statement in a specific scenario over statements in more general scenarios. Its application in our running example for the SP focusing hierarchy $\{{\mathit{SP}}_{\mathit{m}}^1\mathrm{,}{\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}}^2\mathrm{,}{\mathit{SP}}_{\mathit{m}\mathrm{,}\mathit{c}\mathrm{,}\mathit{w}}^3\}$ will indeed generate the argument rules given above in Section 3.1.

Through this automatic translation, argumentation allows us to solve problems without the need to have an exhaustive representation and look up of scenarios and their preferences. The hierarchies allow the user to express the knowledge in less sentences than the generated rules: the rules in the hierarchy are created invisibly to the user. Argumentation provides a principled way to in effect lookup the scenario-based preferences even in cases where the current information is incomplete and/or contradictory.

3.3. The Gorgias system

The Gorgias system was developed as a Prolog meta-interpreter to support the dialectical argumentation process of the framework described above. It was made publicly available on the web in 2003. The system supports queries to find which options are admissibly supported by an argumentation theory. Moreover, it provides the admissible composite arguments that support these options. It also supports hypothetical (abductive) reasoning, integrated with that of its dialectical argumentation, so that it can be used to generate further scenario information under which a desired option would be supported by an admissible argument and, hence, become a possible solution.

As we will see below the Gorgias system was used by several groups to develop applications in various domains. In addition, the Gorgias argumentation framework and its system formed the basis to study several general important problems in AI such as non-monotonic learning [11], intra-agent control [23], multi-agent negotiation and dialogue [20,25], distributed decision making [40], and, reasoning about actions and change [24]. In 2016, a new tool, called Gorgias-B, was released to help the development of applications of argumentation under Gorgias. This tool is presented below in Section 5.

4. Real-life applications of Gorgias

In this section we present an overview of the various real-life applications problems that have been studied with the Gorgias argumentation framework and where the Gorgias system was used to implement and evaluate the argumentation-based approach to these problems. We illustrate one of these applications in more detail in Section 4.1.

One of the first real-life applications of Gorgias [30] was in the area of Medical Informatics, where the problem was to identify what medical actions, e.g., further medical tests or treatment, were needed to determine the seriousness of the condition of a patient with the possibility of Deep Venous Thrombosis (DVT). Medical expert knowledge was captured as Gorgias argumentation theories of different agents with different expertise. The application was build to provide support to medical practitioners and it was tested on a corpus of 600 patients at a hospital in Cluj-Napoca, Romania.

In the general area of Ambient Intelligence Gorgias has been used to address several decision making application problems. One such application, in the more specific area of Ambient Assisted Living [33], was concerned with providing home services for people suffering from cognitive problems, and more particularly from the Alzheimer disease. Personal assistant agents used argumentation to (a) resolve conflicts between competing activities in the user’s agenda (e.g., when the user’s favorite TV show coincided with the time for taking his/her pills) and to (b) take personalized and context-based decisions in special situations (e.g., to reduce a pill dosage when the weather is particularly hot). This work was part of a larger project, called HERA [48], which was successfully evaluated in real-life trials in two phases. The first phase took place at the Hygeia hospital in Athens, Greece, and the second phase at the users’ homes.

Gorgias was also applied to the Ambient Intelligence problem of conflict resolution from networked sensors whose information is incompatible with each other [5]. This enables the development of context aware-pervasive services that can adapt to the application environment. The sensors’ conflict resolution capability was tested extensively using real-life Web services technology, capable of resolving conflicting data gathered from up to 10 sensors. The authors argued that this shows the potential of argumentation theory to solve real-world problems in services computing.

Recently, we have used Gorgias for addressing another problem of conflict resolution, specifically for resolving diplomatic disputes between countries [51]. In another work [26], Gorgias was used in a context where disputes can arise in a shared environment by many stakeholders, where several legal and other contracts may apply.

Gorgias has been used in applications of network security to provide support tools for authoring, analyzing and managing the firewalls of a corporate network [3]. The management of firewalls becomes a challenging task as they grow through new requirements, imposed by the organization. It requires experienced administrators to address these new requirements by creating new firewall rules and inserting them at the “best place” inside the list of the existing rules. The overall aim of this application was to provide an automatic generation of firewall configurations from higher-level requirements and, thus, facilitate their authoring and maintenance. The argumentation-based formulation of firewalls allowed a direct mapping from the high-level network security policy to the firewall policies. Using Gorgias we had an executable firewall configuration, whose compliance to the policy was automatically ensured. This argumentation based approach was applied and evaluated with the firewall specification policy of a moderate-size enterprise, where it was used to examine the properties of the existing firewall and to test that it could automatically generate the relative rule orderings that would ensure the correctness, with respect to the given policy, of the firewall configuration. It was shown that this was possible and that the performance of Gorgias was comparable, on specialized tasks, to state of the art approaches dedicated to network configuration management [53]. In another work [1], following a similar approach of formulating firewalls through argumentation, the authors provided a framework where explanations of the behaviour of the firewalls can be documented and exploited by the administrators and users of the network. Recently, Gorgias was used to study another problem in the area of cyber security, namely that of trying to understand cyber attacks on the Internet and attribute to them a likely source [28]. Although this problem is difficult due to the lack of extensive knowledge on the changing nature of cyber attacks, argumentation gives us a principled way of analyzing the problem that helps in its solution.

Another application of Gorgias was Market-Miner, an innovative agent for automated product pricing, mainly targeted for the retail sector [47]. Market-Miner captures the points of view of different departments of a firm (production, financial, marketing, etc) together with information coming from internal (results of data mining on the corporate database) or external sources (e.g., prices of the competition, weather forecast) and defines appropriate preferences in conflicting scenarios. Briefly, the options considered were at which price to sell a product: normal, high or low price. Scenario-based preferences captured various company policies, e.g., a high pricing scenario when the object of the decision was a high technology product and an advertised invention, or a low pricing scenario when the product’s type was within a category that the company wanted to hit the competition.

A recent application of Gorgias concerned a practical problem of image analysis, namely that of automated discrimination between handwritten and printed text [9]. This problem was modeled as a distributed decision making problem, where the decision about the labeling of text (i.e., “handwritten” or “printed”) is made through a bilateral dialogue between autonomous agents. A dynamic decision making process was set up to deal with the possible dilemmas of the agents in conflicting situations, i.e., when both decisions “handwritten” or “printed” are admissible, based on expert default (or generic) and contextual knowledge for solving these conflicts. Each agent is able to propose, in a dialogue with the other agent, a clear decision based on its own point of view, in order to look for a commonly accepted decision when they have an initial disagreement. The system has been evaluated on real-life data taken from the IAM handwriting database,7

⁷

http://www.iam.unibe.ch/fki/databases/iam-handwriting-database

validating its suitability for several real world applications, such as printed text detection, extraction for Optical Character Recognition and electronic document management systems for handling hybrid documents (e.g., printed documents with handwritten annotations).

4.1. Application in investment portfolio construction

Typically, investors are concerned with constructing a portfolio of assets. One particular type of such assets is that of mutual funds. In this case, a set of candidate funds is chosen, which are then used by the investor to construct a portfolio according to forecasts and personal preferences. The different approaches applied in the literature, e.g., using linear programming, or applying multi-criteria decision aid methods (see for example [42,58]), do not provide the opportunity to an investor to define different investment strategies according to personal preferences, or take a decision in an environment with limited information. The investor can take into account the figures and metrics extracted from previous year(s), the market condition, e.g., bull (rising) or bear (falling) and her/his personal attitude ranging from aggressive (preferring high risk assets that promise high returns) to defensive (preferring known successful assets with low risk and low returns).

In the Gorgias argumentation based approach for this problem [42] the central question was whether or not to add an asset to the investment portfolio. Thus, the set of options were, $\mathit{OPTIONS}=\{\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\neg \mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}$ and the development task was to capture a policy of requirements on the decision between these two options for any given $\mathit{Fund}$ . The scenario information is information about the $\mathit{Fund}$ typically extracted from the variables that measure the performance and risk of mutual funds. This includes the following:

1. return of the funds for the previous period

2. standard deviation of the daily returns of a fund in the previous period

3. the beta coefficient that computes a fund’s risk in relation to the capital risk according to its sensitivity to fluctuations of the general financial market (its index)

4. the Sharpe and Treynor indices for a fund’s excess return based on a risk-free rate or investment.

Moreover, we get scenario information from the expected market condition, which can be unknown, or forecasted as $\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}$ or $\mathit{market}\mathrm{(}\mathit{bull}\mathrm{)}$ . Finally, the investor profile can be unknown or be identified as $\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{averse}\mathrm{)}$ or $\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}$ . With these we can identify several contexts, e.g., type of investor (risk averse and risk tolerant), performance of fund (funds with high Sharpe and Treynor indices), and market context (bull and bear), in which the decision to select or not a fund needs to be considered.

This problem has been captured within a Gorgias argumentation theory constructed along the following lines. First one considers the question of when a fund minimally qualifies to be included or not in a portfolio, i.e., we identify initial or basic scenarios that enable the options. Generally, a fund should not be selected. Only funds with a high return are eligible for selection. This gives the following two scenario-based preferences: $$\begin{array}{l}{\mathit{SP}}_{\mathit{n}\mathit{s}}^1\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{n}\mathit{s}}^1=\{\};{\mathit{O}}_{\mathit{n}\mathit{s}}^1=\{\neg \mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩\mathrm{,}\\ {\mathit{SP}}_{\mathit{s}}^1\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{s}}^1=\{\mathit{highR}\mathrm{(}\mathit{Fund}\mathrm{)}\};{\mathit{O}}_{\mathit{s}}^1=\{\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩\mathrm{,}\end{array}$$ whose translation into Gorgias argumentation theory leads to the object level arguments: $$\begin{array}{l}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\neg \mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\\ {\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{highR}\mathrm{(}\mathit{Fund}\mathrm{)}\}⊳\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}.\end{array}$$ Here $\mathit{highR}\mathrm{(}\mathit{Fund}\mathrm{)}$ refers to the fact that the Fund is in the top 30% of the funds with regard to returns.

These primary scenarios are then refined with the market’s characteristics (forecasts) or the investor’s attitude. Let’s us illustrate some of these and their corresponding scenario-based preferences:

1. the bear market context, where a mutual fund should not be selected unless it has low risk: $$\begin{array}{ll}\hfill & {\mathit{SP}}_{\mathit{b}\mathrm{,}\mathit{n}\mathit{s}}^2\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{b}\mathrm{,}\mathit{n}\mathit{s}}^2={\mathit{S}}_{\mathit{n}\mathit{s}}^1\cup \{\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\};{\mathit{O}}_{\mathit{b}\mathrm{,}\mathit{n}\mathit{s}}^2=\{\neg \mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩\mathrm{,}\\ \hfill & {\mathit{SP}}_{\mathit{b}\mathrm{,}\mathit{s}}^2\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{b}\mathrm{,}\mathit{s}}^2={\mathit{S}}_{\mathit{s}}^1\cup \{\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\mathrm{,}\mathit{lowRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\};{\mathit{O}}_{\mathit{b}\mathrm{,}\mathit{s}}^2=\{\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩\mathrm{,}\end{array}$$

2. the risk tolerant investor doesn’t select funds unless they have high returns and high risk: $$\begin{array}{ll}\hfill & {\mathit{SP}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{n}\mathit{s}}^2\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{n}\mathit{s}}^2={\mathit{S}}_{\mathit{n}\mathit{s}}^1\cup \{\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\};{\mathit{O}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{n}\mathit{s}}^2=\{\neg \mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩\mathrm{,}\\ \hfill & {\mathit{SP}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^2\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^2={\mathit{S}}_{\mathit{s}}^1\cup \{\mathit{highReturn}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\mathit{highRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\\ \hfill & \phantom{{\mathit{SP}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^2\mathrm{(}\mathit{Fund}\mathrm{)}=}\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\};{\mathit{O}}_{\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^2=\{\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩.\end{array}$$

In generating the corresponding Gorgias argumentation theory all specific contexts are to be preferred over their more general contexts. Hence in the general context, ${\mathit{a}}_{\mathit{s}}$ has higher priority over ${\mathit{a}}_{\mathit{n}\mathit{s}}$ (default priority) and we have: $$\begin{array}{l}{\mathit{p}}_1\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}.\end{array}$$

For the bear market scenario/context we have: $$\begin{array}{l}{\mathit{p}}_{\mathit{b}0}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\}⊳\mathrm{(}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{b}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\mathrm{,}\mathit{lowRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\}⊳\mathrm{(}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{b}0}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{b}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_1\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{b}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{b}1}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{b}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}.\end{array}$$

Similarly, for the risk tolerant investor scenario/context we have: $$\begin{array}{l}{\mathit{p}}_{\mathit{r}0}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\}⊳\mathrm{(}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{p}}_{\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{highReturn}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\mathit{highRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\}⊳\mathrm{(}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\\ \phantom{{\mathit{p}}_{\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{}\mathrm{>}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{r}0}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{r}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_1\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}.\\ {\mathit{c}}_{\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{r}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}.\end{array}$$

The application requires that we also considered combined scenarios. For example, the bear market context and risk tolerant investor role can be combined, and, in that case, the risk tolerant investor would accept to select high and medium risk funds (instead of only high). Therefore, we have the additional scenario-based preference: $$\begin{array}{l}{\mathit{SP}}_{\mathit{b}\mathrm{,}\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^3\mathrm{(}\mathit{Fund}\mathrm{)}=⟨{\mathit{S}}_{\mathit{b}\mathrm{,}\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^3=\{\mathit{mediumRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\mathrm{,}\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\};\\ \phantom{{\mathit{SP}}_{\mathit{b}\mathrm{,}\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^3\mathrm{(}\mathit{Fund}\mathrm{)}=}{\mathit{O}}_{\mathit{b}\mathrm{,}\mathit{r}\mathit{t}\mathrm{,}\mathit{s}}^3=\{\mathit{select}\mathrm{(}\mathit{Fund}\mathrm{)}\}⟩.\end{array}$$

Given this we would extend our priority arguments to include: $$\begin{array}{l}{\mathit{p}}_{\mathit{b}\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\mathit{mediumRisk}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{,}\mathit{investor}\mathrm{(}\mathit{risk}\text{\_}\mathit{tolerant}\mathrm{)}\mathrm{,}\mathit{market}\mathrm{(}\mathit{bear}\mathrm{)}\}⊳\mathrm{(}{\mathit{a}}_{\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\\ \phantom{{\mathit{p}}_{\mathit{b}\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{}\mathrm{>}{\mathit{a}}_{\mathit{n}\mathit{s}}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{b}\mathit{r}1\text{\_}1}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{b}\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{b}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}\mathrm{,}\\ {\mathit{c}}_{\mathit{b}\mathit{r}1\text{\_}2}\mathrm{(}\mathit{Fund}\mathrm{)}:\{\}⊳\mathrm{(}{\mathit{p}}_{\mathit{b}\mathit{r}1}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{>}{\mathit{p}}_{\mathit{r}0}\mathrm{(}\mathit{Fund}\mathrm{)}\mathrm{)}.\end{array}$$ The PORTRAIT tool, as it was named, allowed an investor or a fund manager, to select the appropriate funds according to the context (e.g., forecasted situation of the market) and the profile of the investor. Evaluation trails provided evidence that argumentation-based portfolios perform better than the ones based on other, traditional, approaches. The proposed tool was validated using a data set from the Association of Greek Institutional Investors, the Athens Stock Exchange and the Bank of Greece, including daily data of domestic mutual funds, the performance of the market and the return of the three-month Treasury bill respectively, over the period between January 2006 and December 2011. Moreover, the PORTRAIT tool was combined with an evolutionary algorithm for forecasting the market status [49]. This had a good effect on the performance of the system and helped to have the market context changing dynamically for every investment period.

5. High-level development of Gorgias applications

In this section we present a methodological approach to acquire, or machine learn, an application’s knowledge or requirements, in the form of scenario-based preferences. This new approach has emerged out of the experience of the last decade of applying Gorgias to real-life application problems. It allows the high-level development of applications of argumentation where the interaction with the problem domain expert, or user can occur in terms of the high-level language of the problem that the expert is familiar with. The experts do not need to have any technical knowledge of computational argumentation in general, or of the Gorgias argumentation framework.

Our approach allows a domain expert (e.g., medical doctor, lawyer, etc), or a user, to structure their expertise or personal guidelines using the simple structure of a table. In this table, the columns represent the possible options and the rows the scenarios in which the different options are enabled or are preferred. In other words, rows of the table correspond to statements of scenario-based preference. In the case where Machine Learning methods are used, e.g., data analytics, these will operate on the “natural” data of the application (and its operating environment) and will aim to learn the scenario-based preferences of the application, thus filling up a full row of the table. Once we have identified the language of options and description of scenarios the approach follows two basic steps as follows:

STEP 1:

The expert (or user) names the columns of the table after the possible options. Then, s/he fills in the first rows, by defining for each option $O_i$ (or set of options $\{{\mathit{O}}_{\mathit{i}}\mathrm{,}\dots \mathrm{,}{\mathit{O}}_{\mathit{n}}\}$ ) a minimal scenario $S_{\mathit{\alpha }}^1$ in which this option or a set of options are enabled. For each scenario, defined in a row, the expert puts a mark in the columns containing a preferred option. Several scenarios can be possible for the same option (or set of options) and thus we may have several rows with different scenarios concerning the same option (or set of options). We call these scenarios the basic (or initial) scenarios. They correspond to the first level of scenario-based preferences.

STEP 2:

The second step of the approach concerns a process of conflict analysis and possible resolution of conflicts. At the end of the previous step possible conflicts between different sets of options might occur. The reason for this can be (i) that in the same scenario there are several different preferred options, or (ii) that we have different scenarios that are simultaneously possible, as their scenario information can be valid at the same time in an application environment. For the first type of conflict the expert needs to define a next level scenario with new contextual information that narrows down the options range, thus defining a focusing hierarchy. For the second type of conflict the expert declares whether the combined scenario is indeed plausible (i.e it is not inconsistent or completely disjoint) and then considers the preferred options in it.

Some conflicts might still persist and new ones might appear. This process can continue repeating (STEP 2) as long as the expert is able to build further refined scenarios for resolving conflicts. A good practical guideline is to first consider and build hierarchies of scenario-based preferences by iteratively refining scenarios. Once we have such different hierarchies we start considering their combinations, using pairs of hierarchies whose scenarios are different at the lowest levels. We then build hierarchies on top of the combined scenarios. The approach does not impose any restrictions on the expert in making these statements of scenario-based preferences. The only property of the overall preference relation, captured by these statements, is that of being irreflexive, which is a simple consequence of the fact that it is not possible to express a preference of an option over itself in the table. Also note that in practice during these two steps the expert or user may introduce new elements in the language of the problem, particularly relations to describe scenarios.

We note that this approach of gathering requirements in the form of scenario-based preferences of increasing specificity is analogue to a form of evidential reasoning where as we increase the evidence we can make “sharper” decisions. The latter has been studied in AI, ranging from an early work in Inheritance Networks [17] to more recent studies of argumentation and evidential reasoning [44,55].

Table 1 shows an instance of a scenario-based preferences table, being an (intermediate) result at some stage of the process. At the first step the user gives the information in ${\mathit{S}}_{1\mathrm{,}3}^1$ in row 1 of the table and ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ in row 5 (for the subscript of S we will use the indexes i for each ${\mathit{x}}_{\mathit{i}}$ in S). These are two basic scenarios and form the lowest level of two hierarchies. At the next step of conflict analysis and resolution each of the basic scenarios is refined. ${\mathit{S}}_{1\mathrm{,}3}^1$ is refined with ${\mathit{x}}_6$ that narrows down the selected options to ${\mathit{O}}_1$ and ${\mathit{O}}_6$ (row 2). ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ is refined with ${\mathit{x}}_9$ that narrows down the selected options to ${\mathit{O}}_2$ (row 6). Moreover, the table shows the case of a combined scenario where the conditions of both of the basic scenarios hold at the same time. This is at row 7 which requires that the options of ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ are preferred in this combined scenario.

Given these rows, i.e., rows 1, 2, 5, 6 and 7, we see that there are still conflicts as, for example, there is a conflict between options ${\mathit{O}}_1$ and ${\mathit{O}}_6$ under the scenario ${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6}^1$ in row 2. The expert can then examine whether s/he can discriminate between the conflicting options by considering refined scenarios, iterating again STEP 2 of the methodology. When this is possible new rows with refined scenarios are added in the table. For example, a new row (row 3) is added in Table 1 resulting in a focusing hierarchy based on scenario ${\mathit{S}}_{1\mathrm{,}3}^1$ and whose corresponding scenarios are those of rows 1 to 3. Another focusing hierarchy based on ${\mathit{S}}_{1\mathrm{,}3}^1$ is in rows 1, 2 and 4: ${\mathit{S}}_{1\mathrm{,}3}^1$ , ${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6}^2$ , ${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6\mathrm{,}\mathit{n}\mathit{y}}^3$ . A focusing hierarchy based on ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ is in rows 5 and 6 of the table: ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ , ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8\mathrm{,}9}^1$ . In row 6 the option ${\mathit{O}}_2$ is preferred over ${\mathit{O}}_3$ and ${\mathit{O}}_5$ , when the extra scenario information ${\mathit{x}}_9$ is added to the scenario ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1$ .

The table also shows in row 7 that the options ${\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5$ are preferred over options ${\mathit{O}}_1\mathrm{,}{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6$ in the consistent combined scenario $\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\}$ of the basic scenarios in rows 1 and 5. However at a higher level of conflict analysis of this scenario the options ${\mathit{O}}_4\mathrm{,}{\mathit{O}}_6$ are preferred over options ${\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5$ when the additional information “z” holds, thus refining the combined scenario $\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\}$ . This is seen in the last row of the table. This combined scenario defines two more hierarchies:

${\mathit{S}}_{1\mathrm{,}3}^1\mathrm{,}{\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8}^2\mathrm{,}{\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8\mathrm{,}\mathit{z}}^3$ and

${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1\mathrm{,}{\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8}^2\mathrm{,}{\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8\mathrm{,}\mathit{z}}^3$ .

Note that we do not have a combined scenario of rows 3 and 4 as it would contain both y and $\neg \mathit{y}$ and such a combined scenario is not plausible.

It is important to note that the tables of our approach do not need to be exhaustive, or to be built completely from the start before analyzing them. The tables can be built incrementally, provided that each time we expand them, we also introduce a conflict analysis step to ascertain that the expert has information that would help resolve, at least partially, possible new conflicts. One of the features of the approach, and this is due generally to argumentation, is that the expert/user may not be able to resolve all conflicts when they first appear. At a later stage, when extra knowledge has been acquired, the user can discriminate between existing conflicts.

Table 1

Example of scenario-based preferences on conflicting options

row #	Scenarios	Options
		${\mathit{O}}_1$	${\mathit{O}}_2$	${\mathit{O}}_3$	${\mathit{O}}_4$	${\mathit{O}}_5$	${\mathit{O}}_6$
1	${\mathit{S}}_{1\mathrm{,}3}^1=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_3\}$	X			X		X
2	${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6}^2=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_6\}$	X					X
3	${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6\mathrm{,}\mathit{y}}^3=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_6\}\cup \{\mathit{y}\}$	X
4	${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6\mathrm{,}\mathit{n}\mathit{y}}^3=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_6\}\cup \{\neg \mathit{y}\}$						X
5	${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8}^1=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_8\}$		X	X		X
6	${\mathit{S}}_{1\mathrm{,}2\mathrm{,}8\mathrm{,}9}^2=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_8\mathrm{,}{\mathit{x}}_9\}$		X
7	${\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8}^2=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\}$		X	X		X
8	${\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8\mathrm{,}\mathit{z}}^3=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\}\cup \{\mathit{z}\}$				X		X

5.1. Gorgias-B: Authoring tool for scenario-based preferences

Gorgias-B is a Java-based tool built on top of $\mathit{Gorgias}$ for supporting the development of $\mathit{Gorgias}$ argumentation theories.8

⁸

Gorgias-B (http://gorgiasb.tuc.gr) runs under the minimum requirements of a Windows or Linux OS, SWI-Prolog version 7.0 or later, and Java version 1.8 or later. The tool employs Eclipse EMF (http://eclipse.org) technology (with the xtext extension) for managing low level Prolog code and the methodology’s high level concepts and transformations from one to the other.

Gorgias-B has two important roles in the development of applications of argumentation. Besides aiding the elicitation of the expert/user knowledge in the form of scenario-based preferences, Gorgias-B automatically generates from these a corresponding executable $\mathit{Gorgias}$ code. Moreover, Gorgias-B allows us to execute scenarios, i.e., to find out which options are admissible in a given scenario and hence the user can test the generated argumentation theory, during (or after) the development of the application.

In order to illustrate these roles and the general functionality of Gorgias-B we present here how this would be used to capture the scenario-based preferences in the example in Table 1. The tool supports the whole process from its start, where the different options of an application are declared. In the example of Table 1 the expert/user can then use the “Argument View”, shown in Fig. 1, to generate object-level arguments for the declared options, corresponding to the first step of the process of capturing initial scenarios. For example, in the figure we see that the user has selected option, ${\mathit{O}}_1$ , i.e., the option predicate $\mathit{select}\mathrm{(}\mathit{o}1\mathrm{)}$ , and has added the predicate conditions x1 and x3, to form an object-level argument corresponding to the first “X” of row 1 of Table 1. On the left of the “Add argument” button the user can see the scenario based preference that is ready to be added, e.g., “When $[\mathit{x}1\mathrm{,}\mathit{x}3]$ choose $\mathit{select}\mathrm{(}\mathit{o}6\mathrm{)}$ ”. Similarly, for each basic scenario (initial rows) in our table supporting a set of options we generate an object-level argument for each option in the preferred set of options of the row. The six object level arguments are visible in the list at the bottom half of Fig. 1.

Fig. 1.

Gorgias-B: The arguments view (step 1 of the methodology).

Continuing with STEP 2 of the process, the user clicks the button “Resolve conflicts/Argue/Assign argument strength” which opens a new dialogue (see Fig. 2). Gorgias-B identifies scenarios with conflicting options and the user can work on these by selecting (using the controls on the right of the scenario) the option(s) that are preferred (if any) in each conflicting scenario. The user can make these preferences conditional on further contextual information in the scenario under consideration, thus constructing refinements of the scenario. These preference statements appear in the main window as binary preferences or priorities between pairs of options.

In this way, the tool allows the user to enter scenario-based preferences at higher levels of scenario refinements. For example, Fig. 2 shows the conflicting scenario $\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_6\}$ , where the preference corresponding to row 3 for the refined scenario, ${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6\mathrm{,}\mathit{y}}^3$ (see Table 1), is inserted, generating the first priority argument of the two that appear in the box at the bottom of Fig. 2. Then the user inserts the preference corresponding to row 4 for the refined scenario ${\mathit{S}}_{1\mathrm{,}3\mathrm{,}6\mathrm{,}\mathit{n}\mathit{y}}^3$ (seen in Fig. 2 as the second priority statement in the bottom box). Note that the user can navigate the levels of the different hierarchies either by selecting the level at the top of the window or by clicking the buttons at the bottom which are only enabled if the hierarchy has previous or next levels. If a conflict exists at the current level the “Resolve conflicts” is enabled (and shown in red).

Fig. 2.

Gorgias-B: Arguing at higher levels (step 2 of the methodology, second iteration).

Fig. 3.

Gorgias-B: Arguing at higher levels (combination in second level and refinement in third).

By pressing this “Resolve Conflicts” button at the bottom we can move to a next level of conflict analysis corresponding to a new iteration of STEP 2 of our methodological approach. In this way, the user adds the scenario-based preferences identified at the higher-level steps. Figure 3 shows this for row 7 of Table 1, with the scenario ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8}^2=\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\}$ . We can see that priority statements that correspond to the Cartesian product of the set of preferred options, $\{{\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5\}$ , over the options $\{{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6\}$ under this scenario are generated.

Row 8 of ${\mathit{S}}_{1\mathrm{,}2\mathrm{,}3\mathrm{,}8\mathrm{,}\mathit{z}}^3$ in our table indicates, however, that under the more specific scenario $\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\mathrm{,}\mathit{z}\}$ the options $\{{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6\}$ are preferred over the options $\{{\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5\}$ . To capture this, priority statements for options $\{{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6\}$ over $\{{\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5\}$ are entered in Gorgias-B, as seen in the bottom six statements in the left hand side of Fig. 3. These are in conflict with the previous statements of priority of $\{{\mathit{O}}_2\mathrm{,}{\mathit{O}}_3\mathrm{,}{\mathit{O}}_5\}$ , over the options $\{{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6\}$ but Gorgias-B moves to a next level, i.e., level “3”, to resolve these conflicts by generating priority statements for options $\{{\mathit{O}}_4\mathrm{,}{\mathit{O}}_6\}$ under the more specific scenario of $\{{\mathit{x}}_1\mathrm{,}{\mathit{x}}_2\mathrm{,}{\mathit{x}}_3\mathrm{,}{\mathit{x}}_8\mathrm{,}\mathit{z}\}$ (see right hand side of Fig. 3). Gorgias-B sets automatically these higher-level preferences as the most specific context is automatically given preference. Of course, the user can delete unwanted preferences and/or add her own.

The “Resolve Conflicts” button of the level “2” screen (left screen) in Fig. 3 is enabled. This means that in the current scenario Gorgias-B has still conflicting preferences that could be resolved at the next level. As soon as the user clicks this button, s/he arrives at the second screen (level 3) in Fig. 3 where such additional resolution statements from the expert can be entered. As mentioned above, Gorgias-B shows to the user all combined conflicting scenarios except those for which it has information that they are impossible in practice, e.g., combinations where a condition and its negation are present.

Finally, the “Gorgias file” view on the right hand side of the dialogues, e.g., as seen in Fig. 2, is optional and allows the user to see the Gorgias argumentation theory code that is automatically generated as the scenario-based preferences are entered.

6. Current development of applications

In this section we present two real-life applications that are currently under development using the general methodological approach and the Gorgias-B tool described in the previous section.

6.1. Eye-clinic (first level) support

This application concerns the development of a system that can provide a first level support in an eye-clinic by analyzing the symptoms presented by the patient, possibly requesting extra information, with the primary aim to identify the urgency of the situation and thus arrange suitably the patient’s appointment with the doctor.

Sorting the patients and deciding about the urgency of their care, according to the severity of their diagnosed disease, is an important issue for the ocular emergencies departments in public hospitals (or private clinics). An AI-based diagnosis support system would help the receptionist/nurse to make a preliminary (i.e., before a doctor’s examination) diagnosis in order to plan the appointments of the doctors based on the severity of the patient’s condition. The nurse would supply the system with observable (or declared by the patient) facts (e.g., symptoms such as red eye, painful eye, etc.) thus building a current scenario of interest. The system would also prompt the nurse to request additional information when needed (e.g., to measure the intra-ocular pressure or ask the patient about past history) in order to make a more informed diagnosis.

The development of our Eye-clinic support system was based on a collaboration with a highly qualified ophthalmologist doctor of a public hospital in Paris (France) (see [43]). The system is based on the set of known ocular diseases (there are more than 80), which constitute the options in the application’s decision problem. The task is to select the most appropriate ones, given the information gathered from the patient. Options are represented by predicates of the form: $\mathit{ds}\mathrm{(}\mathit{Name}\text{\_}\mathit{of}\text{\_}\mathit{disease}\mathrm{,}\mathit{Severity}\mathrm{)}$ . For illustrating this application we will consider a sub-case where we are concentrating only on four diseases as the set of options. This is given by the following, where the severity of the disease is represented by a number whose higher value indicates higher severity: $$\begin{array}{ll}\hfill \mathit{OPTIONS}& =\{{\mathit{D}}_1=\mathit{ds}\mathrm{(}\mathit{viral}\text{\_}\mathit{conjunctivitis}\mathrm{,}2\mathrm{)}\mathrm{,}{\mathit{D}}_2=\mathit{ds}\mathrm{(}\mathit{first}\text{\_}\mathit{episode}\text{\_}\mathit{uveitis}\mathrm{,}2\mathrm{)}\mathrm{,}\\ \hfill & {\mathit{D}}_3=\mathit{ds}\mathrm{(}\mathit{recurrent}\text{\_}\mathit{uveitis}\mathrm{,}3\mathrm{)}\mathrm{,}{\mathit{D}}_4=\mathit{ds}\mathrm{(}\mathit{suture}\text{\_}\mathit{infection}\text{\_}\mathit{after}\text{\_}\mathit{surgery}\mathrm{,}4\mathrm{)}\}.\end{array}$$

As mentioned above, the scenario information consists of observable facts in various categories, such as the area of the symptom, called zone (e.g., the eye), or the category of symptoms (e.g., red eye, painful eye) or the context (e.g., ocular surgery). We also have other hypothetical information such as whether the patient had (or not) a disease previously. The scenario-based preferences are provided by the expert ophthalmologist by expressing her natural way of thinking about patient symptoms to arrive at an appropriate diagnosis. Basic, or initial, scenarios with minimal information allow for several diseases to be initially chosen. The expert’s analysis of these gives refined or combined scenario-based preferences where the initially preferred diseases are narrowed down or (partly) replaced by other diseases.

In Table 2 we present some of the scenarios that involve the four diseases in our illustrative subset of options. In the description of the scenarios “z” stands for “zone”, “s” for “symptom”, “c” for “context”, “oc_sur” for “ocular surgery”, and “vis_dist” for “visual disturbance”. The expert has identified one initial scenario, ${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}}^1$ , leading to all possible diseases. At a second stage, recognizing the existence of a conflict between ${\mathit{D}}_2$ and ${\mathit{D}}_3$ , in the third scenario, the expert has provided the last two extra (refined) scenarios, where additional scenario information can indeed discriminate this conflict. The refinement from ${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}}^1$ to $S_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}}^2$ narrows down the options but the subsequent refinement of the scenario to $S_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{co}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}}^3$ reinstates ${\mathit{D}}_4$ as the preferred option. The last two rows are two different refinements of ${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}}^2$ .

Table 2

Example of eye clinic application

Scenarios	Diseases
	${\mathit{D}}_1$	${\mathit{D}}_2$	${\mathit{D}}_3$	${\mathit{D}}_4$
${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}}^1=\{\mathit{z}\mathrm{(}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{red}\text{\_}\mathit{eye}\mathrm{)}\}$	X	X	X	X
${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}}^2=\{\mathit{z}\mathrm{(}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{red}\text{\_}\mathit{eye}\mathrm{)}\}\cup \{\mathit{s}\mathrm{(}\mathit{vis}\text{\_}\mathit{dist}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{painful}\text{\_}\mathit{eye}\mathrm{)}\}$		X	X
${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{co}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}}^3=\{\mathit{z}\mathrm{(}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{red}\text{\_}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{vis}\text{\_}\mathit{dist}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{painful}\text{\_}\mathit{eye}\mathrm{)}\}\cup \{\mathit{c}\mathrm{(}\mathit{o}\mathit{c}\text{\_}\mathit{sur}\mathrm{)}\}$				X
${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}\mathrm{,}\mathit{hnu}}^3=\{\mathit{z}\mathrm{(}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{red}\text{\_}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{vis}\text{\_}\mathit{dist}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{painful}\text{\_}\mathit{eye}\mathrm{)}\}\cup \{\mathit{hyp}\text{\_}\mathit{info}\mathrm{(}\mathit{not}\text{\_}\mathit{uv}\text{\_}\mathit{atcd}\mathrm{)}\}$		X
${\mathit{S}}_{\mathit{ze}\mathrm{,}\mathit{sr}\mathrm{,}\mathit{sv}\mathrm{,}\mathit{sp}\mathrm{,}\mathit{hu}}^3=\{\mathit{z}\mathrm{(}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{red}\text{\_}\mathit{eye}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{vis}\text{\_}\mathit{dist}\mathrm{)}\mathrm{,}\mathit{s}\mathrm{(}\mathit{painful}\text{\_}\mathit{eye}\mathrm{)}\}\cup \{\mathit{hyp}\text{\_}\mathit{info}\mathrm{(}\mathit{uv}\text{\_}\mathit{atcd}\mathrm{)}\}$			X

Our methodology has allowed us to structure the high level expertise of an ophthalmologist in several tables in a systematic and flexible way with respect to the complexity and the amount of knowledge that has been acquired. The use of tables provides a compact representation of the expert knowledge, but, more importantly, gives the opportunity to our expert to analyze several times new scenarios based on the combination of basic scenarios when she had to compare and discriminate between conflicting diseases in various existing scenario-based preferences. A prototype is under development and we have already implemented more than 3,000 rules representing object and priority arguments. A commercial product will be subsequently developed to be deployed in the collaborating eye clinic.

6.2. Data access and data sharing

An important recent field of application is that of data sharing. When different stakeholders want to exchange and share data, they need to agree on a common policy, usually referred to as a data sharing agreement (DSA). Recent works [26,27] have applied an argumentation approach within the Gorgias framework for data access and sharing in the health sector. The $\mathit{MEDICA}$ 9

⁹

http://medica.cs.ucy.ac.cy

 [50] system was developed for the purpose of determining the level of access to patients’ data records, according to an EU country’s law on medical data access. There are six different access levels, ranging from full access to various types of limited access and to restricted or no access. All decisions on the level of access reached by the $\mathit{MEDICA}$ system are explained to the user by reference to the relevant articles of legislation, which are, in fact, the basis for the object and priority level arguments that support the reached decision. The system also supports requests from users wanting to gain higher level of access by indicating the extra information that needs to hold, when indeed such higher level access is possible.

More specifically, in this problem the set of Options is captured by the predicate $\mathit{access}\mathrm{(}\mathit{P}\mathrm{,}\mathit{F}\mathrm{,}\mathit{Type}\mathrm{)}$ , where P names the requester, F names a data file and $\mathit{Type}$ takes values in: {full, limitedPlus, limitedPlusReadOnly, limited, suspended, no}, corresponding to the levels of access stipulated by the law.

Table 3 shows a representative case of scenario-based preferences extracted from the legislation. Normally none has access to a medical file. The owner of the file has full or suspended access for personal use. If the file is suspended then the owner has only suspended access. A doctor can have limited plus read only access for treatment purposes. However, even in this case, if the owner of the data is dead access is not granted.

Table 3

A scenarios table. The decision predicate is $\mathit{access}\mathrm{(}\mathit{P}\mathrm{,}\mathit{F}\mathrm{,}\mathit{T}\mathrm{)}$ . Depending on the value of variable T we have the access levels: ${\mathit{AP}}_1:\mathit{full}\mathrm{,}{\mathit{AP}}_2:\mathit{limited}\text{\_}\mathit{plus}\mathrm{,}{\mathit{AP}}_3:\mathit{limited}\text{\_}\mathit{plus}\text{\_}\mathit{read}\text{\_}\mathit{only}\mathrm{,}{\mathit{AP}}_4:\mathit{limited}\mathrm{,}{\mathit{AP}}_5:\mathit{suspended}\mathrm{,}{\mathit{AP}}_6:\mathit{no}$ . Scenario subscripts for contexts: file: f, owner: o, personal use: pp, suspended: s, doctor: d, treatment: pt, dead owner: od

Scenarios	Access Policies
	${\mathit{AP}}_1$	${\mathit{AP}}_2$	${\mathit{AP}}_3$	${\mathit{AP}}_4$	${\mathit{AP}}_5$	${\mathit{AP}}_6$
${\mathit{S}}_{\mathit{f}}^1=\{\mathit{file}\mathrm{(}\mathit{F}\mathrm{)}\}$						X
${\mathit{S}}_{\mathit{f}\mathrm{,}\mathit{o}\mathrm{,}\mathit{p}\mathit{p}}^2=\{\mathit{file}\mathrm{(}\mathit{F}\mathrm{)}\}\cup \{\mathit{owner}\mathrm{(}\mathit{P}\mathrm{)}\mathrm{,}\mathit{purpose}\mathrm{(}\mathit{personal}\mathrm{)}\}$	X				X
${\mathit{S}}_{\mathit{f}\mathrm{,}\mathit{o}\mathrm{,}\mathit{p}\mathit{p}\mathrm{,}\mathit{s}}^3=\{\mathit{file}\mathrm{(}\mathit{F}\mathrm{)}\mathrm{,}\mathit{owner}\mathrm{(}\mathit{P}\mathrm{)}\mathrm{,}\mathit{purpose}\mathrm{(}\mathit{personal}\mathrm{)}\}\cup \{\mathit{suspended}\mathrm{(}\mathit{F}\mathrm{)}\}$					X
${\mathit{S}}_{\mathit{f}\mathrm{,}\mathit{d}\mathrm{,}\mathit{p}\mathit{t}}^2=\{\mathit{file}\mathrm{(}\mathit{F}\mathrm{)}\}\cup \{\mathit{doctor}\mathrm{(}\mathit{P}\mathrm{)}\mathrm{,}\mathit{purpose}\mathrm{(}\mathit{treat}\mathrm{)}\}$			X
${\mathit{S}}_{\mathit{f}\mathrm{,}\mathit{d}\mathrm{,}\mathit{p}\mathit{t}\mathrm{,}\mathit{o}\mathit{d}}^3=\{\mathit{file}\mathrm{(}\mathit{F}\mathrm{)}\mathrm{,}\mathit{doctor}\mathrm{(}\mathit{P}\mathrm{)}\mathrm{,}\mathit{purpose}\mathrm{(}\mathit{treat}\mathrm{)}\}\cup \{\mathit{owner}\mathrm{(}\mathit{F}\mathrm{,}\mathit{O}\mathrm{)}\mathrm{,}\mathit{dead}\mathrm{(}\mathit{O}\mathrm{)}\}$						X

Currently, we are developing the $\mathit{MEDICA}$ application further with the help of a focus group of specialists to assess the applicability of the system for usage in hospitals and health centers. We are working closely with a government advisory team for IT systems for the national health service. This team is evaluating the system from their own IT perspective. Subsequently, we will proceed to evaluate the system through a trial at appropriate medical centers.

We are also working on applications requiring the merging of several diverse policies from independent organizations or people. The main challenge in this is to manage conflicts across policies where we need to understand how one policy’s preference takes precedence over the others. Such is the situation in the data sharing landscape (see e.g., [26,34]). Data is generated in independent and distributed nodes and access to it by different stakeholders is governed by a diverse set of policies. As stakeholders can be independent entities, with their own policies, there are typically several cases where their policies will conflict and in that case an arbitrator is needed to handle the conflicts.

Recently, we proposed a method [4] based on Gorgias for managing such conflicts across different stakeholders’ policies. The main idea is to build an arbitrator meta policy over the individual policies. Following our approach we formulate tables of scenario-based preferences as statements of preferences between the individual policies which take the role of the options for the meta policy. For example, in a medical data access application where we have several stakeholders such as the Patient, Legislation, Hospital and Emergency Organizations (e.g., the Fire Service) such a meta policy can be built from data sharing statements of the form:

“The personal and legislation policies are preferred over others. Among them the personal policy is preferred. However, if the person is a victim in an accident scene, the fire service policy is preferred over the personal one. If the owner of the data is hospitalized, the hospital policy is preferred.”

This approach allows the arbitrator to be agnostic with regard to the individual reasons why a policy allows or denies access and at the same time be capable to arbitrate on such a matter. We are also working on applying such meta policy arbitration to regulate energy consumption in smart green buildings [4].

7. Conclusion

We have presented an approach for the high-level development of a (class) of applications of argumentation that has emerged out of the experience, during the last decade, of applying the argumentation framework of Gorgias to solve real-life problems. The proposed approach allows the modular development of real-life applications, where requirements are processed incrementally in their high-level form, through the systematic analysis of scenario-based conflicts and an automatic translation of scenario-based preferences to corresponding Gorgias argumentation theories and code. Our work shows in practical terms how argumentation is suited to solve problems under incomplete and incompatible information. Argumentation provides a principled and theoretically well founded way to solve such problems providing at the same time explanations for the solutions. The approach is sufficiently general to allow the development of applications in any, of the many existing argumentation frameworks (e.g., [15,38,39]), that support conditional and hierarchical forms of preference.

The approach can be improved in several ways. An important development of the authoring tool of Gorgias-B is the fully automated extraction of the Gorgias argumentation theory directly from the tables of scenario-based preferences so that while these tables are filled the argumentation code can be produced and tested. Given the current investor interest that we have in this we hope to develop a new interface tool for professional use in software companies.

We can also integrate within the application development approach various methods of Machine Learning. For example, scenario-based preferences can be extracted by data analytics on past cases of the application without the need for their explicit stipulation by the domain expert/user. Similarly, by including a feedback process during the operation of the system we can learn new or refined preferences from experience. This feedback can be linked to the provision of explanations that argumentation systems can offer for their operation and decisions. Thus, we are working to extend the explanation facility of our tools to so as to be able to give these in a natural form familiar to the users and to be able to engage in dialogues with the users. In fact, we believe that our approach shows how argumentation facilitates the integration of sub-symbolic Machine Learning methods with Symbolic Computation to build systems that can have a cognitively natural interface with human developers and users.

We are also experimenting with the development of personal Cognitive Assistants in various areas of applications, e.g., personal, tourist, calendar, shopping and social media assistants. This class of applications relies on user guidelines expressed in natural language. A suitable extension of the Gorgias system, called Gorgias-NL [36] is currently under development where scenario-based preferences would be extracted directly from dialogues with the user in structured forms of natural language.