Developing Argumentation Dialogues for OpenMulti-Agent Systems
Bas Testerink & Floris Bex?
Utrecht University{B.J.G.Testerink,F.J.Bex}@uu.nl

Abstract. Dialogue systems attempt to capture aspects of multi-agent
communication with the aim of understanding, improving, and automatically recreating such communication. Though there is ample research into
the formal aspects of dialogue games for argumentation, actual softwareand development tools that allow for the deployment of open, multiagent dialogue environments are lacking. This demo presents the firststeps towards a development framework for an open multi-agent system
in which agents can engage in peer-to-peer argumentation dialogues.
Keywords: Open Multi-Agent Systems, Argumentation Dialogues, AgentOriented Programming

1

Introduction

In [10], we present a generic framework for expressing argumentation dialogues
in open multi-agent systems. One of our motivations is that we aim to makethe development of multi-agent argument dialogue systems more accessible andthus increase the deployment of such systems in realistic, large-scale settings. Asa case-in-point, we are currently developing a prototype multi-agent system forthe Dutch National Police [4], where various agents work together to build a caseregarding internet trade fraud (e.g. scammers on eBay or fake online stores). We
have agents that interact with human users (victims, police detectives), agentsthat exchange information with external services (banks, trade sites) and agentsthat automatically combine and reason with information from these different
sources. Furthermore, the agents communicate peer-to-peer, that is, there is nogoverning middleware or entity that checks the communication. We have opted
for this distributed, open multi-agent system because (i) the police uses strictprivacy policies that make it undesirable to centrally gather and reason with
data; and (ii) not all participating agents in the system are known beforehand– for instance, the human users that file online complaints are unknown.
As our main technique for reasoning we use argumentation [1] this fits thelegal reasoning in the trade fraud cases very well and has as added benefit that?

https://git.science.uu.nl/B.J.G.Testerink/OO2APL-P2PArgumentationDialogDemo
contains a video demo, a working demo and the source code, please see readme.mdwe can make discussions among agents more transparent to human users. Communication among the agents is therefore governed by argumentation dialogue
protocols, which allow us to determine whether a specific message from one agent
to another is legal in the context of the dialogue so far.
In [10] we present our formal foundation for peer-to-peer argumentation protocol specifications based on reusable elements called dialogue templates [5].
In this paper we demonstrate a practical realization of this principle which isa development framework that supports programming protocols and protocolinterpreting agents. Our framework only requires programming knowledge ofJava. Agents that use our modules always have access to the state of dialogue
according to the protocol, based on the messages that they themselves sent andreceived. This view can be exported as a JSON object, so that the decision logic
on what to do with that view (i.e., determining whether to utter a locution, andif so, what the next locution to utter is) can be implemented in another language
if so desired.
Our framework is open-source and we hope that it stimulates the development of argumentation dialogue systems or may serve as an example to otherdevelopers. In this demonstration we present four main contributions: 1) theability to develop protocols, 2) the agent modules that interpret a protocol toautomatically determine which messages are legal and how they ought to beinterpreted, 3) an example multi-agent system that can re-enact dialogues and4) a visualization of the view of an agent on a dialogue, given the protocol.
In Section 2 we discuss the relevant terminology to understand the demo.
Section 3.1 discusses the approach towards implementing protocols. Section 3.2
describes the example multi-agent system for dialogue re-enactment. Finally, 3.3
goes into detail on our example scenario and the visualization. Section 4 discusses
related and future work and concludes the paper.

2

BackgroundArgumentation dialogues [7] consist of a coherent series of locutions, or utterances, made by the participants in the dialogue. Such multi-agent dialogues aregoverned by dialogue protocols, which describe the permitted locutions, how andwhen the dialogue starts and ends, how locutions commit the players to certain
claims and how locutions may be combined into exchanges. Take, for example,
one of the possible protocols for persuasion dialogues given in [7]. The protocol
mandates that a dialogue starts when one agent, the proponent, makes a claim
P, committing it to P . The other agent, the opponent, can either challenge thisclaim by uttering why P, which can in turn be countered by the proponent either
retracting its commitment to P or by providing a supporting argument P since
Q. A claim P can also be attacked by providing a counterargument ¬P since Q.
Furthermore, any argument of the form R since S made by either party can becountered by the other party by giving an argument ¬R since T or ¬S since T .
The dialogue terminates when either the proponent retracts its original claim P
or when the opponent concedes proponent’s original claim P .

Argument 1

Carl is a fraud

ert
Ass

Inference(RA)

Alice:
Carl is a fraud since I paid Carl &Carl did not send the product
As

rt
se

Assert

it
mm

all
en
ge

Co

Intake Agent:
why Carl is a
fraud?

Ch

Alice iscommitted toAssertAlice:
Dialogueclaim Carl is a
(Argument 2)
fraud

Co

mm
it

Alice iscommitted toAlice paid Carl & Carl did
not send the productFig. 1. Example graph combining argument 1 and 2.

For argumentation dialogues it is important to distinguish between argument
1 – arguments as a static structure of premises that are reasons for or against
conclusions (as in, he prepared an argument) – and argument 2 – arguments
as debates or dialogues (as in, they had an argument). The idea is that during
a dialogue (argument 2) the participants construct and navigate an underlying
argument 1 structure of claims and reasons [8]. For an example, consider Fig. 1.
At the top (grey boxes), a simple dialogue in which Alice claims that Carl is a
fraud is rendered, where the arrows indicate the flow of the dialogue. At the bottom (white boxes), the corresponding argument 1 is rendered: from the premise‘Alice paid Carl & Carl did not send the product’ it is inferred that ‘Carl is a
fraud’. The link between argument 1 and 2 stems from speech act theory, wherea speech act is a locution (‘Alice says that Carl is a fraud’), but also an illocutionary act which consists of the illocutionary force, that is, the intention ofuttering a locution (Intake Agent says ‘why Carl is a fraud?’ with the intentionof challenging that ‘Carl is a fraud’) and the propositional content (‘Carl is a
fraud’). Note that the same locution can encompass multiple illocutionary acts:
by saying ‘Carl is a fraud’ Alice not only asserts that ‘Carl is a fraud’ but also
commits herself to this proposition (cf. the small rounded box in Fig. 1).
Two core formal concepts in [10], on which our implementation is based, aredialogue graphs and dialogue templates. A dialogue graph captures the state ofthe dialogue from the point of view of one of the agents. In our implementation,
this graph represents argument 1, argument 2 and commitments (cf. Fig. 1).
The argument graphs in our implementation are slightly adapted versions of
AIF argument graphs [8], which are based on the underlying AIF ontology specification [3]. This ontology places a distinction between information nodes or
I-nodes, to represent locutions or propositions, and scheme nodes or S-nodes, todenote general patterns of reasoning or the relations between I-nodes. Subclassesof S-nodes are RA (Rule Application) nodes and CA (conflict application) nodes.
We further add commitment nodes indicating the commitment of an agent toan I-node.
Dialogue templates define how to update the graph when receiving and sending locutions. They are used to represent dialogue protocol rules, as they containfor each type of locution that is sent or received the possible replies (transitions
to other locutions). For example, one template says that if a why P message is
received, the argument 2 graph is changed to include this locution, the argu-

ment 1 graph remains unchanged, and a P since Q message may be sent back.
Another template says that sending a P since Q message not only updates argument 2 but also updates the argument 1 graph to include Q and the inference(RA-node) between Q and P , and also commits the sender to P and Q.

3

Software Overview and Demonstration

3.1

Programming Protocols

Our framework provides preprogrammed classes that help a developer to specify
dialogue graphs and templates. We preprogrammed the following types of nodes
in dialogue graphs: Argument2Node’s represent locutions that were uttered andedges between these nodes represent transitions from one locution to the next.
AIF I- and S-nodes are implemented as INode’s and SNodes’s. CommitmentNode’s
track which agent is committed to what propositions. EffectNode’s track theillocutionary force of locutions, that is, what the effect of a locution is on theargument 1 graph or the commitments. The default dialogue graph implementation can be extended for added functionalities. This is demonstrated with ourdemo protocol where the DemoDialogGraph maintains a mandate for each agent
what they may utter to what other agent.
Templates can be made by supplying supplying three functions called theguard, response and argument 1 update function. The guard of the templatetells given a dialogue graph and a new argument 2 node whether the template
is applicable. The response function returns, given a dialogue graph and a new
locution, the argument 2 nodes from the dialogue graph to which the new locution is a direct response. The argument 1 update is a function that accepts
a dialogue graph and a new argument 2 node. The template class has a preprogrammed apply-method that for a new message checks the guard, and if theguard passes, applies the response function and argument 1 update. Any changes
that were made during the execution of the argument 1 update are automaticallyrecorded. After the function is applied, the template will create an effect nodethat connects the new message to the changes that were made while executing
the argument 1 update function. A protocol itself is simply a set of templates as
demonstrated in the demoProtocol package.
Finally, we preprogrammed classes for the development of Java-based agentsthat interact using argumentation dialogue protocols. For this we built on top of
OO2APL [6]1 . When an agent receives a message it will check if the sender wasallowed to sent the message by checking whether any of the templates applies
given the current dialogue graph. If not, then the agent immediately replies witha bounce message to the sender. If there was an applicable template, then that
template updates the dialogue graph. The agent can send a message with apreprogrammed send method which automatically does the entire process again,
but for the message to be sent. If the agent tries to illegally send a message it
automatically receives an internal error.
1

https://git.science.uu.nl/OO2APL/

3.2

Re-enacting Dialogues

Our demonstration comes with a dialogue reader which is a multi-agent systemthat can re-enact a dialogue. There are different ways in which the reader can beused. When developing a protocol, one can write manually dialogues (similar touser stories) and see whether the protocol builds the dialogue graph as intended.
For instance in our example scenario we do not want that the intake agent
commits itself in the dialogues with complainants to the fact that someone is a
fraud2 . Another usage is to re-enact the dialogue given a log to trace back whencertain agreements where reached or where some agent violated the protocol.
There are two mandatory input files for the dialogue reader. The first one is
the invitations file, that tells the system who recruited who into the argumentation session. The second input file is the script/log of the locutions that wereuttered. On the Java level the reader further requires a parser from strings (thelocutions in the locutions file) to the locution objects that represent them, andthe constructor of the protocol that is to be used. The reader then reads all thefiles, re-enacts the dialogue, and outputs the dialogue graphs of the agents as
JSON. The re-enactment is done by instantiating DialogReaderAgent agents.
Such an agent’s decision logic when it receives a message is to simply prompt
the next agent to send the next locution in the script.
Note that this dialogue reader multi-agent system can be used as a starting
point: the agents in have a method called handleReceivedArgumentationMessageof which the body can be replaced by a different decision logic on how to respond. Thus, multi-agent systems that include agents with their own knowledge
bases and decision logics can be easily developed.
3.3

Example Dialogue and Visualization

The dialogue reader creates JSON objects that represent the dialogue graphs ofthe dialogue participants, which are visualized on a web page3 . The graph is split
into five components; the dialogue itself, the argument 2 graph, the argument 1graph, the illocutionary force inspector and the AIF graph.
Our demonstration uses an example that is based on our project at the Dutch
National Police, and also strongly resembles the current modus operandi for handling for instance online trade fraud cases. The scenario is that complainants
can file their complaints by interacting with an intake agent and a detective caninteract with an analyst agent. When the detective asks the analyst agent a question, it discusses the question with the intake agent and another agent that may
requisition information from third parties. Our demo thus contains agents that
represent humans, third parties and automated agents. The human agents inour demo are the complainants Alice and Bob, who file complaints that accuse
2

With online trading fraud, your complaint can have all the signs of a fraud casewithout being a fraud case. Roughly speaking, if someone just forgot to send anorder once, then the police will not immediately arrest that person for fraud.
3
see /visualizer/visualizer.html in the demo repositorysome person named Carl of fraud, and a detective, who asks if Carl is a suspected fraudster. The third parties are the Dutch trading website Marktplaats,a bank, and the general administration system from municipalities called GBA.
The automated agents stand in between the other agents. A requisition agent
can demand information from the third parties, an intake agent interacts withcomplainants and an analyst agent interacts with detectives. The requisition,
intake and analyst agent can also interact with each other to discuss topics.
For a visualization of the agents and who is talking to who, see the top
part of the demo page or ‘connectivityGraph.png’ in the screen shot directory.
The agents in our demonstration discuss the topic of whether Carl is a fraud.
The full transcript of the discussion that the agents have can be found in the‘dialogues/intake/locutions.csv’ file. We can click on an agent’s icon in order toinspect its view on the dialogue. As an example we will go through the viewof Alice who files a complaint with the intake agent. In the dialogue tab (or‘dialogue.png’) we can see a timeline with events as observed by Alice. Here, weonly see the messages that Alice sent and received to and from the intake agent.
Initially, Alice claims that Carl is a fraud. The agent replies with a why-challenge
to trigger Alice into defending her claim. She then replies with the argument thatsince she paid and Carl did not sent her package, it must be the case that Carl
has scammed her. To the intake agent it is not obvious why Alice thinks that the
package has not been sent. It therefore challenges this claim with another why
locution. Alice defends her claim by stating that she waited but that the package
was not delivered. The intake agent then concedes the point that the package
was probably not sent by Carl. Alice has nothing else to say so she skips. The
intake agent then asks whether Carl sent any pictures of an ID card and whether
Carl gave his address. Both questions are answered affirmatively by Alice andthe intake dialogue ends.
In the argument 2 tab, we can click on the cluster ‘Alice, Intake agent’ toshow the locutions that were uttered and the response relation among them(alternatively, see ‘argument2.png’). From this view we can see that the protocol
interpreted the dialogue between Alice and the intake agent as three coherent
sub-dialogues. There is a connected graph concerning the topic of whether Alicethinks Carl is a fraud, a connected graph about whether Carl sent picture of an
ID card, and a connected graph about whether Carl gave his address.
The argument 1 tab (alternatively, see ‘argument1.png’) shows the effect ofthe dialogue in terms of argument 1, that is, the propositions that were asserted
or committed to and the inferences that were made. We can see, for instance,that an inference was made from ‘Alice paid’ and ‘The package was not sent’ to‘Carl is a fraud’. We can also see that the agent does not commit to this inference,
nor to the conclusion. This is a desired outcome, since the intake agent ought
not commit itself to propositions regarding criminal facts.
In the illocutionary force tab we can see for each locution how it modified
the argument 1 graph. For instance we can see that the concede locution (clickon locution 6) from the intake agent that referred to the proposition that Alice’s
package was not sent, commits the agent to that proposition (alternatively, see‘illocutionaryForce.png’ in the screenshot directory). Finally, the AIF tab showsfor inference in the argument 1 graph the applied argument scheme and how
the elements are connected to the AIF ontology (cf. [3]). We use in this demonstration only the schemes ‘apply defeasible rule’ for inference and ‘conflict bynegation’ proposition conflicts.
When we look at the dialogue from the detective’s view, then we only see
it ask the analyst whether Carl is a fraud, and immediately see the analyst’s
response that this is not the case. The detective does not see the entire discussion that went on between the analyst, intake and requisition agents about thisquestion, nor is he bothered with the filed complaints. Even though the intake
agent is initially convinced that Carl is a fraud, based on the complaints, theanalyst persuades the intake agent that actually Carl just did not deliver as an
exception to generally bona fide behaviour. Notice that Alice and Bob argue
that Carl is a fraud differently from the intake agent. Even though the intake
agent uses different argumentation rules than Alice and Bob, it can still havemeaningful and useful dialogues with them.

4

Conclusion

In this paper we have discussed our development framework for programmingargumentation dialogue protocols that are suitable for peer-to-peer settings. We
demonstrated this framework with an example that was taken from an ongoing
research project with the Dutch National Police. The framework allows a programmer to make a protocol by specifying the dialogue templates. The software
also provides a multi-agent system that can read transcripts of dialogues andproduces the accompanying dialogue graphs for each participant. The dialogue
graphs are exported as JSON objects, which makes the software also usable toconnect to other technologies through a web-interface. Finally, we demonstrated
a web-based visualization of the dialogue graph JSON objects so that a developer
can inspect the graphs in a more human-readable manner.
Closely related to our framework is the Dialogue Game Execution Platform(DGEP) [2], which is also a tool that helps in developing argumentation dialogue
protocols. The main difference with our framework is that DGEP is not an open
multi-agent framework but rather a middleware platform that, given a locution,
outputs the legal moves. Our framework can be used to program agents thatinteract with the DGEP platform if desired, although this is not strictly necessary
since our agents can interpret protocol specifications themselves.
Future work concerns the research that serves as the basis for this demo. We
have formalized peer-to-peer protocols [10] but certain aspects of the demo, suchas the connection between argument 1 and 2, have not yet been fully worked out.
A further aim is to be able to automatically compile the DGDL specifications [11]of the many argumentation dialogue protocols that are available to a protocol in
the presented development framework. Another major point is the formalizationand implementation of different agent argumentation strategies.

Finally, with respect to intelligent interfaces, such as the intake agent, it isdesirable that humans can interact with such agents in a natural way - whilesome form-based interaction with pre-set choices is fine, there are also situations
in which we would want the human to be able to simply type in natural language text which is then parsed and used by the automated intake agent. In our
project, we have taken first steps to evaluate the possibilities of such information extraction [9] and aim to further develop this in the context of the types of
dialogue explained in this demonstration.

Acknowledgments
This research is part of the project Intelligence Amplification for Cybercrime,
which has been funded by the Dutch National Police Innovation Programme.

References
1. T. J. Bench-Capon and P. E. Dunne. Argumentation in artificial intelligence.
Artificial intelligence, 171(10-15):619–641, 2007.
2. F. Bex, J. Lawrence, and C. Reed. Generalising argument dialogue with the dialogue game execution platform. In Proceedings of COMMA 2014, volume 266 of
Frontiers in Artificial Intelligence and Applications, pages 141 – 152. IOS Press,2014.
3. F. Bex, S. Modgil, H. Prakken, and C. Reed. On logical specifications of theargument interchange format. Journal of Logic and Computation, 23(5):951–989,
2012.
4. F. Bex, J. Peters, and B. Testerink. A.I. for online criminal complaints: From natural dialogues to structured scenarios. In Workshop A.I. for Justice - Proceedingsof ECAI 2016, 2016.
5. F. Bex and C. Reed. Dialogue templates for automatic argument processing. In
Proceedings of COMMA 2012, volume 245 of Frontiers in Artificial Intelligenceand Applications, pages 366–377. IOS Press, 2012.
6. M. Dastani and B. Testerink. From multi-agent programming to object oriented
design patterns. In Engineering Multi-Agent Systems, pages 204–226. Springer
International Publishing, 2014.
7. H. Prakken. Formal systems for persuasion dialogue. The Knowledge Engineering
Review, (21):163–188, 2006.
8. C. Reed, S. Wells, K. Budzynska, and J. Devereux. Building arguments withargumentation: the role of illocutionary force in computational models of argument.
In Proceedings of COMMA 2010., volume 216 of Frontiers in Artificial Intelligenceand Applications, pages 415–426, 2010.
9. M. Schraagen, M. Brinkhuis, and F. Bex. Evaluation of Named Entity Recognitionin Dutch online criminal complaints. Computational Linguistics in the Netherlands
Journal, 7, 2017. To appear.
10. B. Testerink and F. Bex. Specifications for peer-to-peer argumentation dialogues.
In Proceedings of PRIMA 2017, Lecture Notes in Artificial Intelligence. Springer,
2017. To appear.
11. S. Wells and C. Reed. A domain specific language for describing diverse systemsof dialogue. Journal of Applied Logic, 10(4):309–329, 2012.