Conversational agents are in every pocket where a smartphone is. It is the right time to foster a new generation of programmers to give a better personality to these conversational agents. In this paper we propose the dialogware as a novel form of software that should be produced by communication experts and artists: the dialogware programmers. We then introduce a modular FrameNet-based approach to dialogware programming along with a collaborative ecosystem for these new generation of programmers.
Today, conversational agents are everywhere. Every pocket containing a smartphone hides a conversational agent ready to answer questions or to help with some everyday task. Conversational agents are not more con ned in the realm of science ction. They are de nitely among us.
There is a wide range of stable techniques for building these astonishing
conversational agents { a continuum from hand-crafting [
More important than the underlying technique, the key for the success of
these conversational agents is their actual knowledge for reacting to stimuli.
To have credible conversations, this knowledge should be produced or selected
by experts of communication, experts in writing poems, novels or stories, and,
nally, artists. In fact, these people are hired in conversational agent teams of
big players, for example, to de ne Cortana, Microsoft has hired Jonathan Foster
(a Hollywood lm and TV writer) along with other people with the previous
skills [
Hence, this is the dawn of the \dialogware" { a new form of software to program conversational machines. The \dialogware programmers" are the programmers for this new form of software. But, they are not programmers in the traditional sense and with the traditional software oriented mind. Hence, they need more intuitive interfaces.
In this paper, we propose the dialogware programming as a novel way of
programming and we present an associated community-based ecosystem oriented to
dialogware programmers. As any programming model, dialogware programming
is based on modularity and reuse. To foster the development of dialogware
modules, modules are organized using FrameNet [
Building Conversational Agents by Combining Modules
The key point of our model is that conversational agents can be programmed
with reusable dialog blocks and these dialog blocks can be organized using
ontological languages and existing linguistic resources such as FrameNet [
Having FrameNet [
For example, we want to build a conversational agent for a travel agency. The goal of this agent is to gather the information needed to book the travel and the related accommodation. In the rst step, we select the important frames which are Travel and Temporary stay and we select additional dialogs such as the Initial Greetings. The Travel frame has all the frame elements needed to book a trip { source, goal, mode of transportation, traveler and time { and the Temporary stay frame has all those to book an accommodation { guest, duration, time, place and guest. In the second step, we combine the frame dialog blocks to obtain the general dialog (see Fig. 1). The schema declares that the conversational agent starts from the greetings. Once this state is accomplished, the next dialog block is the Travel frame whose dialog aims to ll the free frame elements. The next state is the Temporary stay frame and some of its frame elements are lled with values of the previous state, for example, the goal of Travel lls the place of Temporary stay. In the last step, we ll the dialog blocks which are not de ned. 2.2
To realize the strategy of building conversational agents by combining modules, we need a basic conversational agent technology that keeps tracks of the state of the conversation and has an explicit control of inner variables. These are the only real prerequisites for our approach.
Hence, we use the Arti cial Intelligence Markup Language (AIML) [
Although simple, AIML is enough versatile for hosting the rst version of the dialogware programming paradigm. 2.3
Reusable goal-based dialog modules aims to ll a set of variables by asking questions. These modules based on FrameNet and on ontological resources are extremely interesting when building a goal-based conversational agent. As these modules are one of the key point of our model, we present a way to program these modules in a simple stimulus-response hosting language.
In AIML, we realize these reusable goal-based dialog modules with three main components: (1) a controlling backbone; (2) a set of interaction generators to stimulate answers containing values for variables; and, (3) a set of answer interpreters that capture values for variables.
The dialog module conversation backbone aims to ll all the variables of a given frame. Then, the backbone controls which variable has still to be lled and initiates the dialog for stimulating answers to ll missing variables. This backbone is then called when the state is entered and at the end of each answer interpretation. Given a frame with the variables v1, v2, : : :, vn, the backbone is a stimulus-response pair with the following aspect in a pseudo-language: stimulus: ST ART P OIN T response: cases: v1=;?: call: Request v1 v2=;?: call: Request v2 ... vn=;?: call: Request vn def ault: call: F RAM EDON E where ; is the empty value for a variable. This controlling backbone is called by the stimulus ST ART P OIN T and calls Request vi for the rst variable vi which is still empty. Request vi is the set of interaction generators that stimulates answers for lling variable vi. When all the variables are lled with values, the backbone calls F RAM EDON E. For example, for the frame Travel, variables are Traveller, Source, Goal and so on.
The set of interaction generators Request vi have the following form: where \[Request vi interaction j]" is an actual utterance for asking to ll the speci c variable vi. For example, for the variable Goal in the frame Travel, possible interactions are \Where are you going?" or \What's your nal destination?".
For each request Request vi, there is a set of answer interpreters that are in charge of extracting variable llers from answers given by users. These answer interpreters have the following form:
[A possible answer stimulus: to Request vi with a
variable ller in *] response: set vi to : value that is lling * call: ST ART P OIN T Each answer interpreter captures a form of answer for a speci c request Request vi, extracts the value for the variable with a wildcard , lls the variable vi and, nally, call back the starting point of the dialog module. For example, a possible answer to Request vi for the variable Goal is \I want to go to *". Then, interactions like \I want to go to New York" will be matched and the value of will be New York. The value of will be used to ll the variable Goal. 3
The Dialogware programming eco-system consists of two main parts: the Dialog Diagram Editor and the Frame Editing. This section describes these two main components and the overall implementation details of the ecosystem. 3.1
The Dialogware Diagram Editor is the core of the programming ecosystem. It o ers a graphical interface for the de nition of creating the control diagram of a goal-oriented conversational agent. The diagram editor is composed of two main section: the sidebar and the actual canvas (see Figure 1). The sidebar contains the palette of elements that can be added in the control diagram: frames and static values. When a user clicks on the Add Frame button, the selected frame is imported into the canvas. Then, the application prompts the user to specify the status of the dialogue block in the overall diagram. The main canvas allows to de ne the diagram by creating transitions among blocks (blue solid arrows) and declaring how variables are lled from one frame to the other (green thin arrows). 3.2
The Frame Editing section is used to add interactions associated with the elements of a frame, as well as to add the response pattern to them. The frame editing allows to select the frame and to work on the interactions of the selected frame. By selecting a frame and an element the Frame editor shows the list of all questions associated with the selected frame element (see Figure 2 left panel). Finally, by selecting the Answer's Patterns button, the frame editor shows all the response patterns associated to the selected question. The Frame editor allows to write both novel questions and novel possible answers from di erent users (see Figure 2 right panel). 4
Conversational agents are a rapidly expanding market. We have presented an
approach to develop reusable dialog modules by introducing the dialogware as a
novel form of software. Splitting dialogware programming in blocks is
undoubtedly an e ective approach in terms of software development, as well as being an
e ective method to reduce the overall complexity of building knowledge for
conversational agents. As shown also for serious games [
The community of practitioners of conversational agents is rapidly increasing. Our dialogware programming ecosystem wants to foster a revolution: transforming artists, experts of communication and simple users of conversational agents in developers of dialogware.
In the future, by leveraging on techniques of semantic textual similarity [