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 software and development tools that allow for the deployment of open, multiagent dialogue environments are lacking. This demo presents the rst steps towards a development framework for an open multi-agent system in which agents can engage in peer-to-peer argumentation dialogues.
In [
As our main technique for reasoning we use argumentation [
In [
Our framework is open-source and we hope that it stimulates the development of argumentation dialogue systems or may serve as an example to other developers. In this demonstration we present four main contributions: 1) the ability to develop protocols, 2) the agent modules that interpret a protocol to automatically determine which messages are legal and how they ought to be interpreted, 3) an example multi-agent system that can re-enact dialogues and 4) 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
Argumentation dialogues [
Dialogue (Argument 2)
Alice: claim Carl is a
fraud
Alice is committed to
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 [
Two core formal concepts in [
Dialogue templates de ne how to update the graph when receiving and sending locutions. They are used to represent dialogue protocol rules, as they contain for 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 argument 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 3.1
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 and edges 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 the illocutionary force of locutions, that is, what the e ect of a locution is on the argument 1 graph or the commitments. The default dialogue graph implementation can be extended for added functionalities. This is demonstrated with our demo 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 the guard, response and argument 1 update function. The guard of the template tells 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 the guard passes, applies the response function and argument 1 update. Any changes that were made during the execution of the argument 1 update are automatically recorded. After the function is applied, the template will create an e ect node that 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 agents
that interact using argumentation dialogue protocols. For this we built on top of
OO2APL [
Our demonstration comes with a dialogue reader which is a multi-agent system that can re-enact a dialogue. There are di erent ways in which the reader can be used. When developing a protocol, one can write manually dialogues (similar to user 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 when certain agreements where reached or where some agent violated the protocol.
There are two mandatory input les for the dialogue reader. The rst one is the invitations le, that tells the system who recruited who into the argumentation session. The second input le is the script/log of the locutions that were uttered. On the Java level the reader further requires a parser from strings (the locutions in the locutions le) to the locution objects that represent them, and the constructor of the protocol that is to be used. The reader then reads all the les, 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 handleReceivedArgumentationMessage of which the body can be replaced by a di erent 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
The dialogue reader creates JSON objects that represent the dialogue graphs of the dialogue participants, which are visualized on a web page3. The graph is split into ve components; the dialogue itself, the argument 2 graph, the argument 1 graph, 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 le their complaints by interacting with an intake agent and a detective can interact 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 in our demo are the complainants Alice and Bob, who le complaints that accuse 2 With online trading fraud, your complaint can have all the signs of a fraud case without being a fraud case. Roughly speaking, if someone just forgot to send an order 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 with complainants 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' le. We can click on an agent's icon in order to inspect its view on the dialogue. As an example we will go through the view of Alice who les 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, we only 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 that since 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 a rmatively by Alice and the intake dialogue ends.
In the argument 2 tab, we can click on the cluster `Alice, Intake agent' to show 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 Alice thinks 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 e ect of the 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 modi ed
the argument 1 graph. For instance we can see that the concede locution (click
on 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 shows
for inference in the argument 1 graph the applied argument scheme and how
the elements are connected to the AIF ontology (cf. [
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 this question, nor is he bothered with the led complaints. Even though the intake agent is initially convinced that Carl is a fraud, based on the complaints, the analyst persuades the intake agent that actually Carl just did not deliver as an exception to generally bona de behaviour. Notice that Alice and Bob argue that Carl is a fraud di erently from the intake agent. Even though the intake agent uses di erent argumentation rules than Alice and Bob, it can still have meaningful and useful dialogues with them. 4
In this paper we have discussed our development framework for programming argumentation 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 and produces the accompanying dialogue graphs for each participant. The dialogue graphs are exported as JSON objects, which makes the software also usable to connect 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) [
Future work concerns the research that serves as the basis for this demo. We
have formalized peer-to-peer protocols [
Finally, with respect to intelligent interfaces, such as the intake agent, it is
desirable that humans can interact with such agents in a natural way - while
some form-based interaction with pre-set choices is ne, 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 rst steps to evaluate the possibilities of such
information extraction [
This research is part of the project Intelligence Ampli cation for Cybercrime, which has been funded by the Dutch National Police Innovation Programme.