Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
6987 lines (6333 sloc) 301 KB

Jungian personality in a chatbot

\todo[inline]{Table alteration darker: dark enough now?}

Abstract

\cleared We explore how to add Jungian personality to a chatbot as a process. `Salve’, an existing serious chatbot game, was used as a starting point and closely inspected. We designed personality as a preference for an algorithm rather than value driven decision making, akin to the ideas of Campos cite:campos_mabs2009. In other words, a personality prefers a way of doing things rather than the content they prefer. With this in mind a strategy was devised for adding personality to the existing chatbot in the `Salve’ serious game, while leaving as much of the original architecture in tact. This caused us to replace the existing AIML based scheme with a novel approach. In this approach, we opened up space to have varied responses to a similar utterance depending on the personality. The Drools rule engine is now the center of deliberation in the chatbot. The new modelling method was also less verbose and more precise. We conclude by demonstrating that this scheme works as expected.

Keywords

\quadCleared Jung, chatbot, Drools, YAML, AIML, MBTI, salve, communicate!

\newpage

\newpage

Introduction

\doubleCleared Communication is the foundation of our modern society. Having good communication skills can help individuals in both their professional and personal lives. However training people in communication skills can be difficult. Another party is required to communicate with, and a tutor or teacher has to be there to give feedback.

\doubleCleared Serious games can be used to train people with these kind of skills cite:swartout2013virtual. An example of this is the `communicate!’ game which was developed specifically for medical students. Wherein teachers can create scenarios to let their students practice with communication cite:jeuring2015demo. The `communicate!’ game was script based, the teacher made a scenario and the student would follow the choices predefined by the teacher. A script based game has of course the weakness that a student can’t use creative responses, all possible responses are scripted into the scenario and replying correctly relies on a simple ABC choice.

\cleared To deal with this, an alternative serious game called `Salve’ was made, based on the chatbot Alice cite:augello2016social. To measure how a student performed, a production rule engine was used called Drools. The social practice of a doctor consult was used in this particular instance, in other scenarios other social practices could be used. In this thesis we are interested in extending this work with personalities, where we consider personalities to be a preference for a process rather than content cite:campos_mabs2009. This is useful because it turns out that the issues most doctors struggle with isn’t so much being sensitive, but rather being sensitive to the people who appreciate it cite:clack2004personality. Therefore extending the game so that doctors can train for dealing with different personalities, will help addressing this issue.

\doubleCleared In background section Background we will start by looking into personality theories personality theories, and consider the advantages and disadvantages they have for our use case. Then we’ll discuss agents literature in Artificial intelligence literature. followed by the idea of social practices social practice, and some limited speech act theory Speech act theory. After which we continue with dialogue systems Dialogue systems, some of which can be considered related work. We continue by taking a close look at the state of the existing `Salve’ software that we’re planning to extend in section Salve. Since the personality topic has become quite popular in recent years some thoughts will be devoted to related work in section Related work. With all this in mind, we combine Campos’ architecture with dialogue and Jungian personality as a theory in section Jungian BDI. To make the work in the previous section more concrete, we discuss what architecture was used to implement this in section Architecture. In section Replacing AIML we go into detail why we replaced AIML and with what. Followed by section Implementation in which we discuss a scenario Personality influence case study and how to use the bot Making a scenario, after which we present the test results Testing. Finally we conclude in section In conclusion, in which we also discuss some possible issues Discussion and we present a list of future work Future work.

\clearpage

Background

\quadCleared In this chapter we will discuss the work that is the foundation of this thesis. First we will look at personality theories developed by psychology. Then we will look at some to the literature in AI and argue for the methodologies used, and finally we will look at the serious game in its existing form.

Personality theories

<<personality theories>> \doubleCleared A personality is a set of identifiers that can be used with reasonable consistency to predict behavior cite:mischel2008introductionp3_definition. What we want from this model is a guideline of implementation for the program, that is to say, the more the theory says about internal workings of a person the better it is. We want the model to be realistic of course, but we also want it to be implementable. This is where we have a conflict of interest with the field of psychology since they do not necessarily care about implementation details.

\quadCleared This conflict of interest can be seen for example in cite:mischel2008introductionp4_defpoints, where a criteria of personality is that it should be stable and coherent. However this is a poor software specification since there is no unit of measurement (how long should it be stable, and what range is acceptably stable), but for psychology it is a good definition, because a human can determine out of context what these things are.

\cleared The field of psychology has been somewhat active in trying to model human personality cite:pervin2008handbook. Several frameworks have been developed to figure out people’s personality and what this in turn would mean for their lives. We are interested in two ways in existing personality theories:

  1. Accuracy, if a personality theory does not fit the reality at all it won’t help anyone in the serious game.
  2. Ease of implementation. If the personality theory is too hard (or impossible) to implement in the serious game then we can’t use it.

The field of psychology is very interested in the first requirement. However the second requirement not so much. Therefore our first job will be to list existing psychology personality frameworks, and filter out those that are unfeasible to implement.

The big five

<<OCEAN>> \newlyCleared The first framework we’ll discuss is called the big five. The term big five was first coined in 1981 by Goldberg cite:goldberg1981language. The big five were not big because of their intrinsic greatness, but rather to emphasize how broad these factors were.

\newlyCleared This framework was not really invented, but rather discovered trough lexical analysis by for example Tupes cite:tupes1961recurrent. Although the labels used were different, they conveyed the same idea as the big five model used now. The methodology used is something which is called factor analysis[fn:: In the paper the term `varimax rotational program’ is used, but if we look this term in Wikipedia, we can see the result is called factor analysis cite:varymaxrotanonalprogram]. Factor analysis is a statistical methodology that tries to find underlying hidden variables. This methodology has become widely used in psychology cite:fabrigar1999evaluating.

\doubleCleared The data Tupes used is from Cattell cite:cattell1947confirmation and several others. Cattell used a rating scheme, where a trait was introduced and all test subjects then had to rate all other test subjects as average, below or above average for that specific trait. Subjects were also required to select two extreme trait ratings (max and min) in the subject group. These traits in the test were based on the personality sphere concept which tried to cover the entire surface of personality by providing many small trait areas. Examples of the traits are: `Attention getting vs Self sufficient’, or `Assertive vs Submissive’.

\cleared In the beginning of the 1990’s there were many ways to measure personality that didn’t agree with each other. For example at Berkeley, Block used a 2 dimensional ego-resilience and ego-control method cite:block1980role, whereas Gough measured folk concepts such as self-control, well-being and tolerance cite:gough1987california. Personality researchers hoped that they would be the one to discover a structure that would then be adopted by other researchers cite:pervin2008handbookp114.

\quadCleared The goal of the big five was not to present a new structure that convinced others to use it, but rather to provide a taxonomy that all psychologist could agree upon. Since the big five was so broad (because of the statistical methods used), this worked. Therefore the researchers could keep on exploring there niche with their proffered structure, but once they would present their work they could use the big five to communicate clearly what their research meant without having to redefining the words every time cite:pervin2008handbookp114..116.

\quadCleared The big five as in the OCEAN definition has the following units of measurement:

  • Openness or originality, if you score high on this you enjoy learning new things just for the sake of learning. If you score low then you don’t enjoy this
  • Conciseness, how tidy you are, if you score high the dishes don’t stack up in the sink.
  • Extroversion, a high score indicates you enjoy leading the conversation and you’ll speak up when you disagree with someone.
  • Agreeableness or altruism, a low score would indicate that you don’t want to share and generally don’t trust people.
  • Neuroticism or nervousness, a high score indicates that you like to brag and get upset when someone is angry at you.

\newlyCleared The big five has been extensively tested and the result has been replicated in multiple studies cite:pervin2008handbookp119. One can measure big five score trough a test called the NEO-PI, or the NEO-FFI. The FFI variant is shorter but less precise cite:costa1992revised.

\quadCleared Although these terms may provide a great taxonomy, it does not have any theoretical foundation cite:eysenck1992four. This means it becomes difficult to speak about implementation. To make this more clear we use a thought experiment: Lets say you have a score of 0.8 for Neuroticism, how does this influence my decision for selecting action $a$ or $b$? Now you could say, use a mixed strategy where in you choose 80% of the time the neurotic typical neurotic approach. Then we need a valuation function to decide which of the two actions is more neurotic. But once we’ve done this we still haven’t taken into account any of the other factors. Solving this is a non-trivial endeavor.

\newlyCleared There are some existing solutions in which OCEAN is implemented, for example Allbeck cite:allbeck2002toward used it as a mapping to the EMOTE system, whereas cite:durupinar2008creating used the OCEAN values as a low level mapping in steering behaviors and finally cite:etheredge2016personality used the values for action selection in a dialogue, but extended the descriptions of OCEAN with IPIP with an entire chapter devoted to explaining this. Although these implementations are based on the same OCEAN model, the influence of it has starkly different effects on their respective implementations. Since each of them decided to change the OCEAN model in some kind of way we can conclude that although OCEAN is good for discussing the psyche, it is incomplete for a software specification role.

Personality types

<sec:types> \doubleCleared To address the big five’s issue of having no theoretical foundation we’ll inspect the idea of personality types. We begin with the theoretical foundation proposed by the grandfather of personality research, Carl Jung. After which we’ll look at a theoretical evolution proposed by Myers and Myers-Brigs, which also introduced a structured method of measuring types. Then we’ll discuss some critique on this method. With this criticism in mind we consider some alternatives to the MBTI that have been proposed afterwards.

Jung’s theory of psychological types

<<Jungian types>> \doubleCleared Jung describes several concepts, firstly each person has two attitudes: Introversion and extroversion. Extroversion means dealing with the outside world and therefore is called objective (or observable). Introversion is the world inside a person, and therefore is subjective, or private. These attitudes are mutually exclusive, you can’t do introversion and extroversion at the same time. For example if you’re day dreaming, you’re not paying attention to your surroundings. A person who spends most of his time in the introversion attitude is called an introvert, conversely someone who spends most of his time in the extroversion attitude is called an extrovert. One is however never totally an introvert or extrovert, an introvert can still have extrovert moments and vice versa. It should also be noted that the unconsciousness according to Jung is flipped in attitude. cite:hall1973primer97-98attitude

\newlyCleared Then there are four functions. The first two functions are called the rational functions because they act as a method of making judgements. Thinking is a function that connects ideas with each other to arrive at generalizations or conclusions. Feeling evaluates ideas by determining if they are good or bad, pleasant or unpleasant, beautiful or ugly. Note that this is not the same as being emotional, although you can be emotional and use this function. The irrational functions are called this because they require no reasoning. Sensation is sense perception created by the stimulation of the senses, it can always be rooted to a sense, such as “I see a balloon” or “I feel hungry”. Intuition is like a sensation but it’s not produced by a sense. Therefore it has no origin in the same way as sensation has, and often is explained as “just a hunch” or “I feel it in my bones”. cite:beauchamp2005communication,hall1973primer98-100functions

\newlyCleared To use these functions they have to be combined with attitudes, producing function attitudes. Therefore a person will never be of a thinking type, but rather either a thinking introvert or thinking extrovert. cite:hall1973primer100-101combo We can now imagine what this means, an extroverted thinker will for example make judgements about the real world, and therefore be more like a natural scientist or biology researcher, where they would study natural objects and behaviors. An introverted thinker will make judgement about ideas in his mind, and therefore will be an excellent philosopher, or mathematician, where consistency of the internal reasoning process is important.

\quadCleared Let $\mathcal{J}$ denote the set of all possible Jungian function attitudes such that: \[ \mathcal{J} = \{ T_e, T_i, F_e, F_i, S_e, S_i, N_e, N_i\}\] Where

  • $T_e$ stands for extroverted thinking, which is thinking about objects in the real world. This is thinking with a goal, a problem to solve, to check weather certain laws are upheld, or a system to check. As said before a typical example of $T_e$ based reasoning would be a biologist studying natural behavior.
  • $T_i$ stands for introverted thinking, this kind of thinking could be called deductive, it tries to construct a framework to explain the world. This is consistent reasoning based on internal believes, which does not necessarily solve a problem. A typical example of $T_i$ based reasoning is a mathematician creating or combining new mathematical structures with help of axiomatic logic.
  • $F_e$ stands for extroverted feeling, where objective or external criteria is used to judge, for example something is beautiful or ugly. Established standards may be used to decide this and therefore it’s a conservative function. Decisions are based on interpersonal and cultural values. A typical example of $F_e$ based reasoning is about fashion and fads. Deciding what is fashionable at the moment is an $F_e$ based process. A typical profession would be working at a clothes shop, where the knowledge of the latest trends is crucial.
  • $F_i$ stands for introverted feeling, decisions based on personal values and believes. People who have this as dominant function attitude could be characterized by `still waters run deep’. A typical profession for this type is in counseling or health care, because empathy comes rather natural to them cite:fiproffesionadvice.
  • $S_e$ stands for extroverted sensing, Act on concrete data from the here and now. Then lets it go. People of this type are often realistic and practical. A typical profession driver of heavy machinery or athlete cite:seproffesionadvice, because living in the moment is most important for those professions, this comes natural to $S_e$ based personalities.
  • $S_i$ stands for introverted sensing, acts on concrete data from memories and passed experience. A possible profession for the people with $S_i$ as dominant function is in quality assurance, where the perfect model in their mind can be easily compared to the product in question cite:siproffesionadvice.
  • $N_e$ stands for extroverted intuition, try to find possibilities in every situation. Extroverted intuition can be very good entrepreneurs, seeing ideas in almost every situation, this also makes them very inspiring leaders because they are very excited about their ideas cite:neproffesionadvice.
  • $N_i$ stands for introverted intuition. Looks for new possibilities in ideas. A typical occupation of this type is artist or visionary cite:hall1973primer104nitype, this is because connecting ideas with each other comes natural to this type. However just like the typical artist it may not always be understood why by his peers or even himself.

\quadCleared <<Jungian alternating functions>> Another important concept is the idea of the principal and auxiliary function cite:hall1973primer105principal. The principal function is the one that is most preferred. The auxiliary renders its services to the principal function, however this function cannot be the opposite of the principal. So if Feeling is the principal function than thinking cannot be the auxiliary. This is also true for the irrational functions.

MBTI

\quadCleared The Meyer brigs type indicator is based upon Carl Jung’s theory of personality types. However it brings two important changes, first of all the way of measuring personality type is changed. It uses a structured approach rather than Carl Jung’s projective approach. The responses to items are finite and therefore can be deduced based on theory. In contrast to Jung’s technique where he used open ended answering with word associations cite:hall1973primer23method. Then there is the introduction of an extra index used to order function attitudes cite:carlson1985recent. Which is either a $J$ for judging (rational in Jung terms) or a $P$ for perceiving (irrational in Jung terms). This dimension indicates together with the $I/E$ dimension which function attitude is dominant and which is auxiliary.

\newlyCleared <sec:mbti:order_comparison> Once completed with the MBTI you’ll get character string as outcome, for example `INTJ’. This label tells you indirectly which of Carl Jung’s functions is dominant, auxiliary, tertiary and inferior cite:mccaulley2000myers. In other words it provides a sequence of preferences cite:website.mbtitypedynamics. In case of INTJ it would be: \[N_i > T_e > F_i > S_e\] So the most preferred function to be used by someone of type INTJ would be $N_i$, then $T_e$ and so forth. These are the same functions as Jung used, the MBTI just imposed an order on them cite:mccaulley2000myers,website.mbtisequence. How much preference there is for a function is not encoded in MBTI, just an order of preference. An ENTJ would be similar to INTJ but with a different order: \[T_e > N_i > S_e > F_i\] With this definition the interplay of the judging/perceiving dimension becomes more obvious if we look at INTP: \[T_i > N_e > S_i > F_e\] It’s similar to an ENTJ, but the attitudes have flipped.

\quadCleared A possible grouping of the sixteen type exists using the middle letters: \[\{NT, ST, NF, SF\}\] This grouping goes under the rationale that the first two functions only differ in either attitude, order or both.

\quadCleared Before continuing we would like to say a word about a popular interpretation of MBTI which is based on Keirsey’s book `Please understand me’, and later `Please understand me II’. In this interpretation the sixteen types are also placed in general groups of four but here the $ST$ and $SF$ distinction is replaced by $SJ$ and $SP$ cite:keirsey1998please. It turns out however that Keirsey invented this distinction because `He thought it made sense to group them this way’ cite:whyaretypesdistinct. In doing this he rejected the work of Jung and also that of cognitive functions. Which is problematic because the theory he presented then does not make any theoretical sense. Therefore Kersey’s MBTI will not be used in this thesis.

\quadCleared The MBTI is extremely popular in a sub field called Organizational Development (OD) cite:sample2004myers. But it has gotten some heavy criticism from the field of psychology.

\newlyCleared MBTI has always used a continuous scoring system in the results. However the creators insist that type is enough for making assessment judgments. Since MBTI reduces the test scores to type, it is expected that most of the population would fall into either proposed dimensions. For example $I$ or $E$. This is called a bimodal distribution. However cite:bess2002bimodal suggests this is not the case, but this could be the result of the scores being bidirectional cite:salter2005two. In an extended investigation cite:arnau2003jungian into wether Jungian constructs are truly categorical suggested however that this was maybe not the case and a continuous scale for assessment judgements are required.

\newlyCleared In cite:sipps1985item the MBTI is put trough a method called factor analysis. This is the same technique where OCEAN is based upon (see section OCEAN). With this technique the desired outcome is that there are four question clusters (or factors), one for each dimension. They should be independent, a question that influences $I/E$ score should not influence $S/N$, and finally we expect the factors to indicate differences between individuals, random questions won’t do that. However the study indicated that the MBTI had more than 4 factors (6), they explain the first extra factor as questions that assessed people being `unconditional positive’, but could not explain the other extra factor. Something else of note was that there were questions doing no discrimination at all (not being scored).

\doubleCleared Reliability indicates how often the same result will come out of the test, for example if you take the MBTI a 100 times you may be classified the same type for 70 times, which would be an indication it has a reliability of around 70%. But in psychology another aspect is important, namely the interval in between which the tests are taken, if for example two tests produce starkly different results but a long time has passed between them it’s not considered a big issue. In cite:pittenger1993measuring it is suggested that after a period of 5 weeks 50% of the participants changed in score. However one should take into consideration that after taking the test a first time people could consciously decide to change their opinion because they think it’s more desirable to have a different type. Jung said that type is decided very early on in life cite:hall1973primer106inborn, so reliable scoring is important.

PPSDQ

\cleared The PPSDQ keeps basically the same theory as MBTI cite:kier1997new,king1999score, but uses a different measuring method. Instead of forced questions it uses a word-pair checklist for $I/E, S/N$ and $T/F$ scales, and for the $J/P$ scale self describing sentences are used cite:melancon1996measurement. An example of a word pair checklist can be found in table tab:word-pair-example. The word pairs themselves were obtained by prescribing an exploratory test(s) to a sample in which the proto PPSDQ was submitted and also the MBTI itself, factor analyses was used to determine correlation, this is done in cite:thompson1994concurrent. The optimal amount of points (options to choose from) presented in such a test is a subject for debate. Common sense would suggest that more points would give more precision, but in cite:matell1971there it is suggested that reliability and validity do not increase with more points. In cite:garland1991mid however they state the importance of an available midpoint. The 5 point choice format in the PPSDQ is not motivated.

WordWord
Empathy12345Logic
Dispassionate12345Emotional

\newlyCleared The result of the PPSDQ would look something like: $I-30,N-20,T-80,J-60$, with a scale of 0 to 100. This means the tendency for introversion would be about 30, and similarly for the other dimensions. Note that $I-30$ is the same as $E-70$, introversion and extroversion being on opposite ends of the same scale. As an application, we can for example make a preference sequence, where higher valued functions come first, or create a mixed strategy, where we select functions based upon probability.

\cleared The PPSDQ is measuring the same thing as MBTI but lacks the criticisms of MBTI. The reliability is for example between 90% to 95% with a delay of two weeks. The internal consistency was also measured which proved to be better than MBTI but there was still a dependency between $S/N$ and $P/J$ which remains unexplained cite:kier1997new. The PPSDQ is internally the most consistent of the discussed alternatives (excluding OCEAN) cite:arnau1999alternative.

SL-TDI

\quadCleared SL-TDI measures functions by presenting 20 situations and then giving subjects possible actions which correlate with the functions. The subjects then have to indicate how likely it is that they would choose that particular action cite:arnau2000reliability.

\quadCleared It becomes rather straight forward to make a function preference of the measurement of SL-TDI since the question directly measures the Jungian functions. A possible personality type therefore would be: \[ S_i \geq T_i \geq S_e \geq F_e \geq N_i \geq T_e \geq N_e \geq F_i \] To determine the preference we just used the observed value in the test. Since every situation offers a choice for each function with a 5 point value there is no need for normalization.

\quadCleared This denotation is much less strict than the MBTI or PPSDQ since it does not force alternating attitudes or pairing of rational/irrational functions in the preference. Therefore the amount of personality types SL-TDI supports drastically exceeds that of the PPSDQ. In other words, there always exists a mapping from PPSDQ to SL-TDI, but not always from SL-TDI to PPSDQ. The reason for doing this is because there is experimental evidence that there exist personalities outside of the structure originally imposed by MBTI and the subsequent PPSDQ cite:loomis1980testing.

Comparison of theories

\quadCleared To re-iterate, we are interested in a framework that is realistic, and easy to implement. The Big Five falls short on the easy to implement, there is no underlying theoretical framework to support it cite:eysenck1992four, therefore we cannot base our implementation on anything except our own interpretation.

\quadCleared The MBTI has been criticized a lot from the field of psychology, but it does have a solid theoretical foundation. There is some relation between the big five and MBTI cite:furnham1996big. Therefore it’s somewhat realistic, but quite easy to implement.

\newlyCleared Both of the alternatives of MBTI use a continuous scale and have a high correlation with the big five cite:arnau1997measurement. This means is that they are measuring something which is also measured by the big five in some way.

\quadCleared The PPSDQ is based on the same theory as MBTI, but with scaled type letters. To convert the type to function attitudes some extra work has to be done, namely calculate their respective probabilities. To decide which function attitude to use some kind of mixed strategy has to be used. The PPSDQ is more realistic, but at the cost of being more difficult to implement.

\doubleCleared The SL-TDI is even harder to implement than the PPSDQ because the function attitudes no longer have to alternate. This either means that functions are independent (thereby rejecting some of Jung’s work), or that they have to work in some kind of combination. If they work in some kind of combination and we have the following preference: \[ T_e > T_i > S_i > N_i > F_e > N_e > S_e > F_i\] We select the first function to work with, but it requires some information, which we can only get from an irrational function. So what do we do now? Select $S_i$, thereby skipping $T_i$, or select $T_i$ and let it decide to select $S_i$, but this would basically give $T_i$ censorship rights. This is difficult to answer therefore it is a lot more difficult to implement than PPSDQ. Since SL-TDI drops an assumption, which is shown with experimental evidence to be false cite:loomis1980testing, we can say SL-TDI’s theory is most realistic, but this comes at the cost of being even more difficult to implement.

\quadCleared Therefore our preference for implementation is the following: \[ \text{MBTI} > \text{PPSDQ} > \text{SL-TDI} > \text{OCEAN} \]

\doubleCleared There is another hidden reasoning behind this, the work of PPSDQ can built on that of MBTI, and that of SL-TDI can build on that of PPSDQ. OCEAN lacks theory and builds on statistics, however since SL-TDI and especially PPSDQ have a statistical relationship with OCEAN cite:arnau1999alternative, Jungian theory can be used quite realistically with an eventual statistical mapping mapping back to OCEAN.

Agents

<<Artificial intelligence literature>> \quadCleared In the literature there is little consensus on what exactly an agent is, however there is a general consensus that an agent is autonomous cite:wooldridge2009introduction. To make this more clear we’ll use Wooldridges’ definition:

An agent is a computer system that is situated in some environment and that is capable of autonomous action in this environment in order to meet its delegated objectives.

\doubleCleared In another older definition cite:wooldridge1995intelligent Wooldridge highlights autonomy, social ability, reactivity, and pro activity. Where autonomy means that no human intervention is required, social ability means it can talk to other agents, reactivity is that it can reply on input and pro activity means that it can show behavior while not reacting to something. However he later continues on with a stronger claim: An agent is a piece of software that uses concepts which are attributed to humans, such as believes desires and intentions.

\quadCleared This is the reason why we can’t call any program an agent. For example an operating system kernel is autonomous (a user would never interact with it), social (can do networking), reactive (it will comply to hardware interprets for example) and proactive (a process hogging to much memory will be killed without the process asking for it). However we won’t call a kernel an agent because it doesn’t even come close to having believes, desires or intentions.

\cleared Something to keep in mind is that there are three `branches’ of agent research cite:wooldridge1995intelligent. The first one is agent theory in which specifications and methods of specifications are developed. They ask what are agents and what are they ought to do and how do we tell them that, we describe some in section bdi logics. Then there are the agent architectures, these address questions of how to implement the specifications written by the theorists. Although we already got an architecture described in section The serious game, we will explore some more in section Fatima Architecture. To show some comparable architectures to our own. Finally there are the agent languages, which ask the question how to write agent programs. This again is mostly predetermined for us, but we briefly mention some in section Drools background, to juxtapose with our approach.

Belief desires and intentions

<<BDI explained>> \quadCleared The belief desire intention model of human practical reasoning was first introduced by Bratman cite:bratman1987intention. It is based upon a `common sense’ framework of human reasoning.

\quadCleared The idea of BDI is that an agent has believes, these can be anything, such as I believe the grass is green, or I believe the keys are on the table. Note that we never speak about facts, an agent can believe something to be a fact, but that doesn’t make it a fact. Desires are special kind of believes that give agents a reason to be, they may also be called goals. Intentions are (partial) plans to make a desire come to fruition. How to formalize this properly turns out to be a hard question, which is analyzed in the following section bdi logics.

\quadCleared A number of reasons have been stated to use this methodology. The foremost is to make agent orientated systems less expensive in maintenance, verification and construction according to Rao and Georgeff cite:rao1995bdi. However they don’t cite a source for this.

\quadCleared Another paper argues in favour of agent orientated design cite:jennings2001agent. It has the following major arguments: It is effective to divide a complex problem domain into several smaller problems, abstracting in an agent orientated way is more `natural’, and complex systems dependencies and interactions can be easily modeled.

Intelligent virtual agents

<<Fatima Architecture>> \tripleCleared Intelligent virtual agents are systems that emulate characters, that not just move but have human like abilities cite:aylett2013intelligent. Because of complex cognition and planning mechanisms they are able to deal with dynamic social environments autonomously.

\doubleCleared We can consider the Fatima architecture cite:dias2005feeling as an intelligent virtual agent architecture. In this the OCC model cite:steunebrink2009occ was used to define and track emotions in their respective agents. They also defined `personalities’ trough value based limits on emotions, decay rate variances, goals, reaction rules and action tendencies. These don’t follow the theory discussed in section personality theories. Note that the Fatima architecture is an extension upon BDI cite:lim2008improving.

\doubleCleared We can consider the architecture of the `Salve’ game discussed in section Abstract architecture already a virtual agent architecture. It for example also has an emotions module which also is grounded in OCC cite:augello2016social. So it is only natural to say the architecture discussed in section Architecture, is also an intelligent virtual agent architecture. This thesis did not try to unify OCC based emotions with personality, moving Drools to the core of deliberation could make this easier however (see section Drools background). More extended use of social practice, and the recombination of OCC could in future work lead to an agent that can chat much more naturally than just another Alice bot.

Logic of BDI

<<bdi logics>> \cleared Logic of BDI is an attempt to formalize how agents behave. One of the first formalization of Bratman’s theory was that of Cohen and Levesque cite:cohen1990intention. It was based on linear time logic and used operators for actions and modalities for goals and beliefs cite:meyer2014logics. It also used a tiered formalism, with at the bottom belief goals and actions which provided the basis for the higher achievement and persistent goals and intentions to do and be. Rao and Georgeff introduced a different formalism that used branching time logic. They use modal operators for belief desires and intentions and then put constraints on them to make interactions meaning full cite:meyer2014logics. Therefore this formalism is much closer to that of Bratman cite:rao1991modeling. Finally there is the KARO formalism which is based on dynamic logic. This is the logic of actions and computation. They extend this logic with epistemics to add believes to it cite:meyer2014logics.

Drools

<<Drools background>> \doubleCleared If JADE cite:braubach2003jadex, and 2APL cite:dastani20082apl are agent orientated programming languages, then Drools can be seen as a more low level variant. Things such as goals and ontology are not predefined in Drools but there exists a concept of rule matching similar to 2APL. Drools is called a production rule system, which is based around the RETE algorithm cite:droolsdocs. A good example in which Drools is used is the expert system called OptaPlanner cite:vcimbora2015usability, which is a constraint satisfaction solver trough heuristics by using Drools.

\doubleCleared Drools consists of three major concepts. First of all there is the data model, which are just java classes. This data model is called the fact base. Then we have the rule queries, or left hand side. These indicate when a rule should be executed by analyzing the fact base. Finally there is the right hand side, which is java code that gets executed if the left hand side becomes true. This code can modify the facts, or interlope with outside java code trough global variables. Also note that Drools is Turing complete cite:weppenaar2011solving. An example of a drool rule can be seen in listing code:drool:example.

rule "Create default reply"
when
	$symbol_database:SymbolDatabase()
then
	log.info(drools.getRule().getName());
	delete($symbol_database);
	insert(new DefaultReply($symbol_database.get("nonsense").orElseThrow(
		()->new RuntimeException("I can't find nonsense anywhere :s")
	)));
end

\doubleCleared With listing code:drool:example we can also see the difference between facts and globals. The facts are used as values to execute Drools upon. In the example this is the SymbolDatabase. Globals are interactions with objects that live outside of the rule engine. Such as the logging object log in the example.

\cleared An interesting difference between traditional BDI model and Drools is that Drools speak about facts. In section BDI explained that we never speak about facts, however drool does call the main data model the fact base. Drools is of course not a BDI agent programming language and does not need to keep to the established BDI taxonomy.

BDI + Personality

<<BDI + Personality>> \newlyCleared There have been several works that attempted to combine BDI with personality theory. In cite:gmytrasiewicz2002emotions emotion and personality is taken together and modelled formally. Similarly to the Fatima architecture there is no personality research cited in this work, just research on emotions. However this formal model could be useful regardless of the lack of personality theory, especially the observation that there are only three possible transformations as the result of emotions: Transformations of actions space, transformations of the utility function and transformations of probabilities of state. We mention this because we do transformations of action space (irrational functions) and utility functions ($F_e$ modifies itself) in section rational process. The transformations of state idea may seem foreign to us: Personality never changes in our architecture. However we do have the believes $B$, which could be seen as the state of mind of an agent. Therefore we do this transformations whenever we change the believe base.

\doubleCleared In cite:canuto2005personality the personality model of Millon was used, they chose to interpret it as a value based personality scheme. Where the values would indicate probability of action selection and quality of behavior. If an agent would get several tasks the one he selects depends on his personality values and the quality of execution also depends on personality. Tasks could align or not align with personality depending on the task. A drawback to such an approach is the necessity of mapping values of the personality to the required actions. We do this to some extend in the symbol graph with perlocutionary values for example, but this is only necessary when certain personalities need to follow different routes (see section steering bot), besides the irrational functions do something completely different.

\cleared In cite:campos_mabs2009 Campos presents a methodology for adding personality to BDI agents. What is novel about his work is that rather than presenting personality as value driven, it emerge from the process an agent prefers. So personality defines the reasoning approach an agent will use according to Campos. This was called process orientated rather than contend orientated. cite:campos_mabs2009 For example in their interpretation of MBTI a sensing agent would make a plan before hand in complete detail (strict evaluation cite:sheard2003pure), whereas an intuitive agent would continue planning as the situation demanded from the agent (lazy evaluation cite:launchbury1993natural). Thinking agents would base their decision process upon their own believes whereas feeling agents would consider what other agents want. In our model we conceptualize the Jungian functions also as a process. We comment more on this in section Jungian BDI.

Social practice

<<social practice>> \doubleCleared In cite:reckwitz2002toward, practice theory is described as an example of culture theory, from this we can deduce a reason why the study of such theory would be relevant: It can help us explain context in for example dialogue, trough expectations norms and social effects. In contrast to more classical models such as the `homo economicus’ where self interest and goals are most important, and `homo sociologicus’ in which group values are most important. Both these classical models ignore the unconsciousness layer of knowledge humans of same cultures share. Using the social practice model that doesn’t ignore this layer, could lead to a more `natural’ conversation with a chatbot.

\cleared In cite:smolka2001social it is stated that the research in activity theory led to the development of social practices. It was Karl Marx who thought of the `roots’ of activity theory cite:engestrom1999perspectivesp3_marx, Activity theory tries to bridge the gap between a single actor and the system it resides in trough the activity in progress cite:engestrom1999perspectivesp10_broad_definition. Another way of describing activity in this sense is `a way of doing things’. A problem with this model however was. How do cultures move activities from the collective towards the individual cite:smolka2001social? Social practices were therefore introduced to make the notion of activity more concrete.

\doubleCleared An early adoption of social practice can be found in cite:shove2005consumers, where it was used to analyze the spread of Nordic Walking. In his analyses he uses the following overarching concepts to analyze the practice:

  1. Material, which is just stuff in the real world. Such as cars, lamps etc.
  2. Meanings, which covers issues that are relevant to the material and/or the practice. Think of health, price or even emotions. In cite:shove2005consumers meanings and images is used interchangeably, however in cite:holtz2014generating it’s labeled as just meanings. For clarity we will be using the word Meanings since it’s more descriptive.
  3. Competence, to participate in the practice of cycling, one needs to be able to ride a bike. These abilities is what competence encompasses.

\cleared In cite:dignum2014contextualized a model of social practices for agents was developed. This model is extended specifically to allow software agents to use it. In this model physical context describes the physical environment, it contains resources, places and actors. Note that resources is equivalent to material from the model used by cite:shove2005consumers,holtz2014generating. Social context contains a social interpretation, roles and norms. In the previous model this was all part of Meanings. Activities are the normal activities in the social practice, in Nordic walking this can be for example talking with your partner, or stopping to get a stone out of your shoe. They don’t all need to be performed, but are there just as options. This is the first construct that wasn’t covered by the other model. Plan patterns is a default that is assumed for all ways the social practice is used. They are concerned with order of activities, certain activities have to happen before other activities. An example of a doctor appointment plan pattern can be seen in figure fig:sp-activity. If you go to the doctor the first thing you do is some kind of greeting. Then the doctor goes onto data gathering and diagnoses mode until he figured out what’s wrong. After which he will tell in the finishing phase what to do about it. Now what these phases entail is not clear at all. Finishing may for example contain the prescription of medicine, or an appointment to go to the hospital. However plan patterns do not describe such an implementation, and only constraints on eventual concrete plans. These constraints can be either very loose such as described above, or in certain cases very tight. For example it may be established a doctor can only end the conversation if they asked their patient if they understood everything. This still isn’t a concrete plan, since how this is asked isn’t described. The plan pattern construct wasn’t represented in the previous model either. Meaning in this model is solely related to the social effects of activities, and finally Competences is the same as in the previous model.

\quadCleared The interest for this model comes from the potential heuristic use of social practices. Once in a particular situation that fits for a social practice the amount of reasoning can be sped up by having actions and their preconditions be grouped under that social practice, if no preconditions match an agent could consider trying other social practices he knows, or ask its peers for more information.

\doubleCleared The social practice theory in this thesis should be considered as a foundation rather than a separate element. Potentially it could give the notion of culture or even common sense to agents. In this thesis we are interested in implementing personality for a serious game in a single social practice. So right now the social practice just gives an ordered overview in what domain our program should work. We can formulate the social practice that is relevant for this thesis in the following manner:

  • Practice name: Doctor appointment
  • Physical context,
    • Resources: Computer, chair, diagnostic tools..
    • Places: waiting room, doctor’s office…
    • Actors: doctor, patient, assistant, …
  • Social context,
    • Roles: Doctor, Patient…
    • Norms: doctor is polite, patient is polite, doctor is inquisitive
    • Social interpretation: Can sit on chair, cannot sit on table.
  • Activities, share information, do diagnostics, minor treatments, prescribing drugs…
  • Plan patterns, see figure fig:sp-activity.
  • Social meaning, awkwardness, gratitude, …
  • Competences, Give injection, empathetic talk

#+RESULTS[7a43fec1ceafd4b5f5a5ceaf9e08cbc3996b06c6]: fig:sp-activity img/uml/sp-activity.png

\doubleCleared We can imagine personality should have a influence on social practice selection and of course plan influence. As far as the authors are aware however, there hasn’t been any prior work on this subject, but we can speculate for example that when considering physical context someone that is domination by a sensing extroverted $S_e$ function attitude would check all facts more rigorously than someone dominated by an introverted intuition $N_i$ function attitude.

\quadCleared If the social practices are defined more formally they could be used in a bigger system such as in cite:augello2015social and cite:augello2016model.

\FloatBarrier

Speech act theory

<<Speech act theory>> \quadCleared Since a large part of this thesis is about communication we will give here a brief overview of speech act theory. There are three levels at which speech acts can be analyzed according to cite:shoham2008multiagent_speechact_p241..245. Locutionary acts simply convey information form the speaker to the listener. All speech acts do this, as long as they carry meaning. Illocutionary acts are the speech acts that do something by saying it. It captures the intend of the speaker. This includes giving orders or uttering a warning. Perlocutionary acts are the acts that bring an effect to the hearer, such as scaring or saddening.

\newlyCleared There are some basic assumptions of conversation, commonly described as the rules of conversation developed by Grice cite:shoham2008multiagent_speechact_p241..245. Human communication happens on the assumption that both parties want to be clear to each other, even when other motivations apply. This is called the cooperation principle. To accomplish this shared goal the Grice’s maxims cite:gricemaxims are used: Quantity has to do with the amount of information transferred in a single utterance, a human wants to transfer just enough to get the right meaning across. Quality is the assumption where people will say things they believe to be true. Relation states that the things uttered should be relevant to the subject being discussed. Manner is about being as brief and clear as possible while avoiding ambiguity and being orderly.

Dialogue systems

<<Dialogue systems>> \quadCleared Dialogue systems are the systems that try to analyze how dialogue works. This is a sub field of AI that tries to combine linguistics with computer science.

\quadCleared First of all are of course the chatbot systems, which are based upon case based reasoning. A good example of this is the Alice bot cite:wallace2001don. These are mostly reactive systems that use pattern matching rules paired with `good’ responses, sometimes with conditions to allow for more variety. Another example of such a system is Eliza bot which is described in cite:galvao2004persona, where they also added personality to the bot with the OCEAN model.

\quadCleared Traum cite:traum2003information describes the information state approach for dialogues. The approach Traum proposes is modeling:

  • Informal components, which aren’t part of the model but are just there. This can include domain knowledge for example.
  • Formal representations, which are data structures.
  • Dialogue moves, which entail the set of possible utterances to make.
  • Update rules, that allow or prohibit the taking of certain moves.
  • Update strategy, to decide what rules to apply at a particular point.

The dialogue is the information state itself cite:walterapproaches. This is an extremely general way of describing a dialogue system.

\doubleCleared Both Alice and Eliza fit in this system. Alice for example provides dialogue moves trough AIML and the update strategy is simple pattern matching. You could consider topic tags to be an update rule. The formal representation is then also AIML itself. A similar mapping can be made for Eliza.

\quadCleared In cite:wobcke2005bdi a BDI based methodology is proposed to handle dialogue between a user and an agent. However we want to point out that this solution fits into the rough model Traum sketched. So we could say its a information state approach too.

\quadCleared An interesting paper on dialogue modeling can be found in cite:bilange1991task. What is interesting is that they treat having multiple options available in their implementation (see 3.3 in the referenced paper). This is similar to what we present in section Dialogue tree. Although their solution is quite different, rules were made to select according to a single strategy, whereas we saw it as an opportunity to make composable strategies. This is of course an information state approach too.

Salve

<<The serious game>> \quadCleared This chapter describes the game we inherited from our predecessors. We have to discuss precisely what they did for two reasons:

  1. To help understand the design constraints we work under
  2. To distinct our changes from theirs’

    \cleared

There have been several distinct versions of the `communicate!’ game. The first version was a web based game, with a scenario editor. cite:jeuring2015demo However it had some drawbacks, for example each dialog was scripted by the teacher and the answers the student could give were specified by the teacher. This made practicing on it somewhat unrealistic. In this case practicing would mean memorising what button to click rather than to figure out what to say.

\cleared To address this issue a new implementation was made. This version was based around the idea of a chatbot, which allowed users to give open answers rather than selecting buttons. The Alice chatbot was used as a foundation and the AIML language was extended to allow emotional reactions of the agent. This new language was called S-AIML cite:augello2016model.

\quadCleared A specific scenario was created for doctor/patient interaction cite:augello2015social. The game in this version also has the ability to judge the skills practiced cite:augello2016social, such as following certain protocols (politeness, medical standards), and empathy.

\doubleCleared There is a difference between the architecture in the published papers and the source code received. This is because the source code is actively being worked on, whereas the papers are snapshots of the source code at the time of publishing. An example of such a difference can be seen if we take cite:augello2016social in consideration, the judgement of these practices was for example encoded within the S-AIML language, however in the source code AIML has taken a step back. It is only used for text processing and not deliberation (which is now being taken over by Drools as discussed in existing architecture). Section Functionality and Abstract architecture, are based upon the published papers, however for sections existing architecture and Server architecture, we will be using the source code as a reference when discussing the existing work because it is more relevant.

Functionality

\quadCleared There are two major functionality perspectives to consider, that of the student, and that of the teacher. We will consider these in separate subsections since in game they don’t interact.

Student usage

\quadCleared For a student to use the application he has to first start a client. He can now choose to start a new game. There are options to list existing games but these have not been completed. Once in game the user enters a screen as can be seen in fig:client:

./img/client.png

\quadCleared From here the student can start practicing, the game will track his progress on the server.

Teacher usage

\doubleCleared For the teacher there is no client right now. The way a teacher can setup a scenario is trough modifying AIML and drool files. The teacher probably needs an expert to do this because to load these one needs to do a build. Which can be quite difficult for the first time, as seen in appendix building.

Abstract architecture

\quadCleared An abstract architecture was already in place and described very well by cite:augello2016social. This can be seen in figure fig:abstract-architecture, which was directly taken from cite:augello2016social.

./img/abstract-architecture.png

\doubleCleared The Interaction module handles user interaction, where the GUI can show the dialogue and the mood of the agent. The Dialogue module inside it however handles low level string interpretation with help of AIML (see section Text Processing), this basically works trough string matching. Note that although represented in the abstract architecture as the same module, the GUI resides in the implementation on the client side whereas the Dialogue module resides on the server.

\doubleCleared The Dialogue module calls directly the Representation and interpretation module, with help of specialized tags (see section Deliberation) information can be inserted in the Representation and interpretation module.

\doubleCleared Both the Representation and interpretation module and the Score module use drools to do their respective tasks. The only real separation in implementation is trough directory and file structure, at runtime there is little distinction. The only other thing of note is the direct connection between the Emotion module and the GUI, this is done because the Emotion module sends directly messages to the GUI whilst ignoring all of AIML.

Application Architecture

<<existing architecture>> \doubleCleared The game uses a client server architecture (see figure fig:components). The client is written in unity and the server is a Java application running on Wildfly. Communication between the two applications happens trough a web socket. A web socket is used because it allows the chatbot to be pro-active, which is more difficult with a technology such as REST.

#+RESULTS[6554c350da9b80944f22f0c6c29686b4608b9b50]: fig:components img/uml/components.png

Source tree

\quadCleared There are two major source trees tracked in separate version control systems. The first manages the client[fn::received on commit =40b55c0da1f556ba2b66ea8322d72008c9df1e72=] and the second the server[fn:: received on commit =92f12fc26a7da83554903bfe7c6ed1cc64dd5a53=]. The protocol is tracked separately in the respective client and server folders with the folder name dto.

Protocol

\doubleCleared The protocol is setup to be intended for a much larger system. There are hints of a registration system but further inspection revealed that only logging in worked and was required. This is tied into the server’s ability to run multiple games. There is also limited monitoring functionality, the active games can be listed with a specialized message. A typical happy path scenario of protocol messages is listed in figure fig:sequence.

#+RESULTS[db5e6bada22b64bf70a330d1219fedc990f11453]: fig:sequence img/uml/sequence.png

Server architecture

<<Server architecture>> \doubleCleared We will discuss the server architecture in more detail since it contains the `brains’ of the application. The most important classes are shown in figure fig:class. WebSocketService is the entry point for the program where the messages from the client enter.

#+RESULTS[da1283423804d9bccc8868552768b582306da369]: fig:class img/uml/class.png

\doubleCleared The WebsocketService uses a ChatbotEngine to determine how to reply to user utterances, Where ChatbotEngineImpl is the concrete implementation. ChatbotEngineImpl uses a KieSession for the Drools and a Chat which is the Alice bot interface. Once a startGame message is received the KIE service is started, which runs on a dedicated thread to do drool deliberation. At this point facts can be inserted for the Drools to react upon, in case of the anamnesi scenario the GameStart fact is inserted, which is a marker object to indicate that the game has started. This allow Drools to take the initiative, for example when the user hasn’t replied after 20 seconds the agent will ask the user why he hasn’t replied yet. A detailed overview of construction can be seen in figure fig:construction.

\doubleCleared In the class diagram (figure fig:class), we can see an attribute to the Chat class called predicates. This is a bag of variables the Drools can use to keep track of the scenario progression. The setGlobal method of KieSession is used to expose global objects to Drools. In this case the ChatbotEngineImpl is exposed. Insert can be used to insert facts. The difference between facts and globals is explained in section Drools background, the summery is that facts are `just a value’ and globals are used as communication with external libraries (for example the WebSocket and ChatSession).

#+RESULTS[3acde42e45cb6f546f0d34b2c135845e8f592a48]: fig:construction img/uml/construction.png

Text processing

<<Text Processing>> \quadCleared Text processing is done with help of the Alice chatbot. This bot does the parsing and validation of AIML, with help of the knowledge encoded in AIML it can specify a response. AIML links a pattern to a template, where the pattern is a user input and a template a response. An example of a pattern template pair can be seen in listing code:aiml-example-why-here.

	<category>
		<pattern>
			What is the problem
		</pattern>
		<template>
			<srai>why are you here</srai>
		</template>
	</category>
	
   <category>
		<pattern>
			* why are you here
			</pattern>
		<template>
			<srai>why are you here</srai>
		</template>
	</category>

\doubleCleared In this example the first category indicates that if a user types “What is the problem” (pattern tags), then the answer can be found in a category with pattern “why are you here”. The second category does the same but the star indicates that any amount of characters [fn::It is not really `any’ character, we investigate this further in section Star tags] before the pattern can be ignored to match with the category.

Deliberation

<<Deliberation>> \quadCleared AIML has been extended to allow updating of the Drools knowledge base, as can be seen in listing code:s-aiml-inserts.

<category>
    <pattern>why are you here</pattern>
    <preconditions>not healthProblemAsked</preconditions>
    <template>
        <insert packageName="sp.anamnesi.health_problem" typeName="HealthProblemAsked" />
        I'm experiencing a <getDroolsTemplate />. It's quite strong.
    </template>
</category>

\todo[inline]{Investigate if Drools rule have to update precondition hashmaps individually? (Or if this is done automated? Well you could automate it so I think it doesn’t matter). I think we should talk more about this?} \todo{Now I’m like, noo it just doesn’t matter} \doubleCleared In this case if a user utters the sentence: “why are you here”, the bot will check the drool database what his problem is and also update the scenario. Once the scenario is updated the possible responses of the chatbot are changed, as can be seen by the precondition tag. The template tag has some extra tags. The insert tag inserts a fact into the Drools knowledge base, the getDroolsTemplate tag queries the Drools knowledge base for a string.

User utterance processing

<<user utterance processing>>

\quadCleared An important process to describe is the way currently user messages are processed. Figure fig:utterance-proccesing gives a detailed overview of utterance processing.

#+RESULTS[f9f1a787a2ef8d9859808313637ca06b328116d6]: fig:utterance-proccesing img/uml/utterance-proccesing.png

\cleared As can be seen in the diagram the message processing happens inside the Alice bot. Tags were added to AIML to allow the drool engine to be updated. The drool system can be relatively easily be bypassed. If there are no tags in AIML the drool system will be oblivious of chat messages. We represented this situation in figure fig:state:aiml, there is a clear choice between going from a pattern either to Drools or to the template. If there is an insert tag then the `Drools’ state is visited, if not we go directly to the `Template’ state. Then the `Template’ state can use getDroolTemplates tags to read information from Drools. Note that there is a loop for the getDroolTemplates tag in figure fig:utterance-proccesing. This is because a blocking queue is used, which will block the thread until there is an item in the list. This is represented in the state diagram as the ReadDroolTag state.

#+RESULTS[e004be8f35a1f147fb2883719a5fb53bf630e02b]: fig:state:aiml img/uml/figstateaiml.png

\clearpage

Related work

<<Related work>> \doubleCleared In this chapter we will give a brief overview of various interesting papers we found during researching this topic. We will start with chatbots in general, each of which has a wildly different approach to perform the same task. Then we will discuss chatbots that also have personality. Finally we will discuss the reasoning behind the direction we chose.

Chatbots

\quadCleared One of the first chatbots was ELIZA, made as early as 1966 cite:shawar2007chatbots. It recognized keywords and based on the linguistic context chose the appropriate transformation. The keyword file and its associated transformation rules were called the `script’.

\newlyCleared The Alice chatbot is a more recent incarnation of the idea, but uses AIML as a basis for the `script’ cite:wallace2001don. Because Alice is licensed under an open source license, and the AIML has been standardized, a legion of other implementations have been made that all can parse AIML. In fact the `Salve’ game discussed in section The serious game, used AIML to deal with natural language. In section AIML issues we discuss our reasons to move away from this almost traditional chatbot paradigm, but in short: We can’t use AIML for adding personality unless we’d modify it in such a way that it no longer is AIML. The primary reasons is that AIML selects a response when a pattern is matched, the template, however we want to have the ability to choose between various responses. This `choice’ will then be the personality as a process. We call this the problem of not having deliberation `space’.

\newlyCleared In cite:vinyals2015neural a sub symbolic chatbot is presented that uses machine learning. It appears that it can handle the general cases of conversation, even questions it didn’t train upon. The authors state that its answers are sometimes on the short side, and that slight variance in semantics can result in inconsistent answers. Another issue we have with such a methodology is that it’s a completely opaque process. Although you could probably emulate personality by training on specific sets of data, the problem than becomes how would you decide what data is part of which personality? An interesting idea is however to try and use the technique discussed in this paper as a drop in replacement for pattern matching, this is discussed more in section Replace regex.

Multilogue

<<Related multilogue>> \cleared In another interesting paper cite:penning2007boosting, multilogue is already possible. However this design is drastically different from the one we presented. In this paper they tried to improve input understanding, because it was difficult to hand write in their system, therefore the process was automated. Although in the end there were still several open problems left, such as not being able to deal with what we call templates, or what AIML calls star tags. They also seemed to have problem with context, which we partly solved with scenes. On the other hand it is more advanced in that it can construct sentences, whereas we predefined them.

Personality in chatbots

\doubleCleared To simulate personality in communication games there have been already several works proposed. Etheredge used the OCEAN personality theory to create argumentative agents cite:etheredge2016personality. Although argumentation is not the same as communication, we can consider the method used to make the personality. In this paper a personality model is introduced based on OCEAN. They move from personality values in OCEAN towards action selection with fuzzy logic. Fuzzy logic `obfuscates’ `crisp’ values with more `natural’ terms: Rather than writing ${1,2,3}$, we can use `low, medium, and high’. With these terms, business rules can be specified. A big advantage of this is that we can modify the definition of the natural terms without modifying the rules they specified. An example of one of these rules is: “if actions is high or self consciousness is high then acceptance is favored”.

\newlyCleared This has a major disadvantage in that a lot of rules need to be added to do action selection (there are 54 described in the paper), some of which become quite big (for example, some have 7 conditions). This can make action selection opaque. It is for example not immediately clear how a higher anxiety will influence action selection. Having a lot of rules also makes maintenance hard, if for example there is an unwanted behavior many rules need to be inspected before the change can be made.

\cleared There are two strategies that could help dealing with this: Modularization which is partly already done in the paper by splitting up action selection and action revision for example. Another approach is to simplify the model, which could be done by using OCEAN traits rather than the facets, reducing the amount of variables from 16 to 5. In fact this will make the argumentative bot a lot more consistent with the OCEAN model. Since some facets were used for action revision and others for action selection, we can have an agent that will revise as if it is very high neurotic but select as if it were very low neurotic. A reason for the complex model maybe the inherent lack of theory OCEAN provides.

\doubleCleared Van den Bosch also chose to use OCEAN to model characters in a serious communication game cite:van2012characters. He used a nested probabilistic if else structure to decide on how agents should interact. His methodologies had some shortcomings however, for example: A not agreeable person was defined as someone who’d had a high probability of telling facts about himself, which in certain situations could be considered strange, for example a spy who was captured. This kind of methodology is called content orientated cite:campos_mabs2009. Depending on context the personality should change, with which social practices can help.

\cleared In cite:galvao2004persona an architecture is presented to add personality trough AIML. This paper is interesting because it uses AIML where we explicitly wanted to avoid it (see section From strings to meanings). The paper does not base itself on a particular personality theory but offers a `modular architecture’ so that the developer can customize them to any particular personality model. This is explained with some examples in cite:galvao2004adding, it can specify its state and personality in AIML, and then check upon that with `if, then’ rules in the templates. Aside from the fact that this is practically unmaintainable verbose and stretching AIML and XML to its limits (see section xml vs everything), it’s also not very modular since now everything is in AIML. Constructs for dealing with modularity such as type safety and even object orientation are just not available if everything is put in AIML.

Campos

\tripleCleared Campos used the MBTI to create BDI based agents cite:campos_mabs2009. In section BDI + Personality we already discussed Campos his architecture. We will use a more fine grained version of MBTI, but his architecture is used, in which personality will be processed orientated rather than content orientated. It is more fine grained in that we use Jungian functions instead of MBTI type labels. The details can be found in section Jungian BDI.

\clearpage

Dialogue as a personality process

<<Jungian BDI>>

\newlyCleared This chapter tries to answer the question: What is personality from a computationally perspective? We imagine personality being a preference towards a process rather than a preference towards content. We will however not consider yet how to place this in the existing system, but will consider how to model Jungian psychology with BDI into a dialogue process. We want to make personality as a process work, while trying to introduce as few assumptions as possible, and we want these assumptions to be as small as possible. We want to make the system work, while keeping it simple, because simplicity matters cite:hickey2012simplcity.

\doubleCleared We do this first by analyzing what we want to do in section Differences from Campos, then we propose a rough solution in section Informal description of Jung + BDI. However since that solution is very rough we use type signatures in section A type signature approach to be more precise. This leads us to discuss the dialogue tree Dialogue tree and symbol graph symbol graph, which are two core components. Then we make a model that can combine individual functions in section Composing types. After which we will look into the specific function attitudes and how to implement these as behavior in section Rational and irrational. In section Practical changes we will discuss some changes that were the result of testing. Finally we will consider how this presented method relates to Jungian theory in section Consistency with theory.

Differences from Campos

\quadCleared Campos cite:campos_mabs2009 first considered how to combine MBTI with BDI. His reasoning domain was however in action space (rather than just dialogue), but we still want to use the idea that personality is a preference for a process rather than a preference for content as discussed in section BDI + Personality. However rather than using MBTI dimensions we want to use Jungian functions. This is because Jungian function attitudes are the underlying construct of MBTI and several other instruments (such as the PPSDQ and SL-TDI).

\cleared There are some differences from the theory discussed in sec:types and Campos’ process. The difference is that in the discussed theory we would translate MBTI to the underlying Jungian functions, whereas Campos used the measured dimensions. Translating to the functions has some advantages, by doing so we are for example not bound to just the MBTI. We also get more accurate descriptions of what Jungian functions are, Jung described in his work people with that particular function as dominant. This is harder to do with the dimensions, because if you take an INTJ type and an INTP type the semantics of both the $N$ and $T$ change because of the $P/J$ dimension, as can be seen in their respective order (see section sec:mbti:order_comparison). Campos avoids this by ignoring the $I/E$ and $J/P$ dimensions, resulting in a simplified theory. However we would like to note that it is not an easily extendable simplification. Therefore we chose to translate types to orders in Jungian function attitudes, something which is already done by MBTI.

\cleared Another consideration to make is what are these function attitudes? By which I mean what do they represent in computer science terms: programs, objects or functions? What should they be? Since Jung wasn’t much of a mathematician cite:jungonfunctions it’s just an informal definition. However we can make a mapping to certain BDI processes based upon their description, but before that is done we need to make several structural observations. Firstly functions attitudes are not independent, by which we mean that the function attitude resulting behavior of $a$, followed by $b$ is different than $b$ followed by $a$ (see section sec:mbti:order_comparison). Jungian functions do not have the commutative property. Secondly all functions should be used and their order matters. The first function used should be most prevalent. This means that we can’t just execute all functions and do a preference selection on the result.

\quadCleared We will interpret the Jungian functions attitudes as a mapping from an agents believes and senses towards an agent action and new believes. This is then reduced to the scope of a chatbot in the social practice. After this we will look what extra information the function attitudes need in an attempt to reduce the amount of possible believes.

Core idea

<<Informal description of Jung + BDI>> \doubleCleared Before diving into the type signature approach, we want to give an overview of the core idea. Firstly we see the Jungian functions as a unit of processing. This is a clear design choice, there are alternatives. One could for example choose to make a unit of processing for every possible combination of Jungian functions attitudes which would result in eight factorial different units of processing, or specifically just for MBTI which would result in $16$.

\newlyCleared We also chose to model function attitudes, rather than functions and attitudes. The reason for taking them as a combination is that there are more precise descriptions available for function attitudes, rather than functions and attitudes separated

\cleared A Jungian function attitude as a unit of processing is something where information goes in, the function does its processing and then information comes out. This is analogous to a mathematical pure function. Another way of describing such a process is a transformation upon information. From this we used the idea which MBTI uses too, that these small processing units are in an order, this order determines the eventual personality. What we do is to combine the units of processing into a chain. This chain will then receive the information, which each unit can transform. The information will pass trough the entire chain, to give each unit a chance. The result is then a piece of information too: One part being the reply, and the other being the agents’ believes.

\cleared There are several phases of processing going on in the entire chatbot. Firstly we have user message parsing, where we try to figure out what the user said. Then, secondly there is action generation, where we use the parsed message to determine sensible replies. After that there is action selection, of which the best action is chosen. This action is finally handled by the surrounding system. The opportunity for personality exists in practically all phases. In the first phase for example we can do filtering based on the type of messages received: A Thinking based personality may filter the message “how are you” as an inquiry based on “how is your disease?”, or “why are you here?”, whereas a feeling based personality may retrieve a different meaning, as in “how are you doing in live generally”? We chose to not do such kind of personality based filtering because it requires actual understanding of the message received.

\cleared There exist techniques such as convolution kernels cite:moschitti2004study to decide what was said which can be combined with owl cite:world2012owl to simulate a sense of understanding. However implementing such techniques is considerably out of scope of this thesis, and even with the existence of such techniques separately, it’s still questionable if one can combine them successfully.

A type signature approach

<<A type signature approach>> \newlyCleared To give a better understanding of the scope of this project we will try to come up with a type signature of a pure function that models all the function attitudes. We do this with a Haskell like syntax cite:jones2003haskell, in which the arrows indicate a function, left of the arrow is called a domain and the right side a codomain. The domain is also called the argument of a function. If we see a pattern like $a → b → c$ means $a → (b → c)$ or give an $a$ and return a function $b → c$, this process is called partial application cite:haskellpartialapplication. Capital letters indicate sets. Note that we have an overview of the symbols used in appendix Symbol overview. Also note that if we have a function $a → a$ it does not mean that the value of $a$ stays the same, it just means that the type $a$ is used which may change in value. For example think of a function from an integer to an integer that increases the value by four, which also has a signature like that.

\doubleCleared We will go from an as broad as possible system (while using BDI) to a precise as possible definition, while still being able to satisfy the domain. This is desirable because it will restrict the amount of computation branches that can happen inside the function. For example a pure function with type $b → i$ where $b$ is a boolean and $i$ an integer, can only produce two possible integer values, because there is no more input information to make decisions upon. Therefore making the domain as small as possible will result in a less complex system.

\doubleCleared To start we’ll postpone modeling interplay between the $f_a$ function attitudes and define a type signature for them working individually. To do this we will define some terms, with which we will go from the broadest definition possible towards one that fits the project scope precisely.

\newlyCleared Let $\mathcal{B}$ denote the set of all possible believes and let $B$ with $B \subseteq \mathcal{B}$ denote the believes. $Π$ is the set of all possible sense information, in which $π$ with $π \subseteq Π$ denotes the perception information. $\mathcal{D}$ denotes the set of all possible actions, and $Δ$ indicates the set of actions executed where $Δ \subseteq \mathcal{D}$. With this definition we can define every possible agent configuration[fn::Note that this is just the deliberation part, there is no memory in a pure function, but the agent’s memories can be stored in the believes. The believes can be reused in the next call, it’s up to the caller to decide how this happens. This can be done on the thread of control the agent owns for example. Where it will block until a new perception $π$ comes in from the environment.] as the following pure function type signature: \[ B → π \overset{f_a}{→} (B, Δ) \] This says, we first put in the current believe base, then the sensory information after which we get a new believe base and a set of actions. In this the intentions are encoded in the function used, and the desires are part of the believe base. We marked the $f_a$ arrow, which indicates the deliberation process of the agent, so $f_a$ can be any of the function attitudes discussed in section sec:types.

Narrowing the model

<<Narrowing the model>> \doubleCleared This definition is however too general for our domain. First of all the set of sensory information can be reduced to a string, since this is the information we get from a user. We can go even further by saying all chatbots do the same thing namely a mapping $σ → σ$ where $σ$ is a string, where the domain is a user string and the codomain the bots’ reply. Therefore we could express all chatbots in the following manner: \[ B → σ → (B, σ) \] Where $B$ are the set of believes of the chatbot, or its state. We can model all chatbots in this manner because if they don’t have state $B = \{ \}$.

\quadCleared However a string is still to broad since going from a textual representation to a deliberation process is difficult. Therefore we will introduce another mapping function $g$: \[ σ \overset{g}{→} s \] Where $σ$ is a string and $s$ a symbol where $s ∈ \mathcal{S}$ in which $\mathcal{S}$ stands for the set of all encoded symbols[fn::Originally this was called meaning with an $m$, but we want to avoid confusion with meaning in the social practice, and therefore renamed it to symbol, as in symbolic representation]

\quadCleared A symbol $s$, where $s = (\{σ\}, σ)$ has the first value as a set of potential returning strings to utter, and the second is the name of the scene the symbol occurs in. The scene name is used as a name space and a crude way to measure scenario progression.

\quadCleared With this we can define another function $g’$: \[ s \overset{g’}{→} σ \] This allows symbol $s$ to be decoded into string $σ$. Note that in this relation there can be multiple $σ$ that map to the same symbol, but one symbol produces only a defined set of strings $\{σ\}$, that in turn map to itself, on this a random selection can be made.

\newlyCleared The simplification is now as follows, firstly we note that $\mathcal{S} ⊂ Π$, since understanding symbols is a form of sensation. Then we can define $S \subseteq \mathcal{S}$ which stands for the symbols the agent understood. This allows the agent to do deliberation without having received any symbol (empty set). Which leaves us with the following type signature: \[ B → S \overset{f_a}{→} (B, Δ) \]

Dialogue tree

<<Dialogue tree>> \newlyCleared We have some believes and symbols going in, some deliberation going on and a new set of believes and actions going out. However this type signature isn’t enough. To allow the agent to select action in a rational manner, we use a dialogue tree to model the options. The root of the tree is the utterance we deliberate upon. The ply under that is the utterances we consider in response to that. With plies under that in turn being responses to those, etc.

\newlyCleared We need to mark which agent uttered what in the dialogue tree nodes, therefore we introduce $Λ$ as the set of all active actors, where $a ∈ Λ$. With an actor $a$ and a symbol $s$ we can start thinking about modeling an utterance around which we can model dialogue tree nodes. However to do this, it’s important to remember that an utterance always comes with a perlocutionary value set as discussed in section Speech act theory. Therefore we introduce the set of all encoded perlocutionary speech acts as $\mathcal{P}$ of which a set of speech acts is $P \subseteq \mathcal{P}$. With this we can define utterance $u$ as a tuple: \[ u = (P,a,s) \] Where $P$ is the set of perlocutionary values uttered, $a$ is the actor that uttered and $s$ the symbol that was uttered.

\newlyCleared Now we introduce $D$ a dialogue tree tuple: \[ D = (u, [D])\] Where $u$ is the utterance, and $[D]$ is the ordered list of dialogue children. The initial dialogue is just a symbol with an empty list of children. To consider a reply, we would use the same dialogue tree, except with a list of children that is bigger than zero. The most preferred reply is the first element in the list of children. How the actor decides will be discussed in section symbol graph. An example of an expended dialogue tree can be seen in figure fig:dialoguetree.

#+RESULTS[cd0e7e478418a395091db0d14239c8421fe35813]: fig:dialoguetree img/uml/dialoguetree.png

\doubleCleared With this in place we can replace both the $S$ and $Δ$ with the $D$ and $D$ respectively, we can also remove $t$, since it’s now contained in the utterance. This is convenient because now we can model function attitudes as processing units that take a dialogue tree and modify it. We are left with the following type signature: \[ B → D \overset{f_a}{→} (B, D) \] So we receive a dialogue tree from the user, which can just be a root node, and then after processing we put out a dialogue tree plus the replies which are the children, whereof the first child is the most preferred. Note that this $f_a$ function is an endomorphism, meaning that the input arguments are of the same type as the output arguments. We annotated the output arguments with $t+1$ to indicate they could’ve been changed, not to indicate a different type.

\doubleCleared Now we should note that this type signature heavily constrains our agent. It for example can’t handle being punched in the face by the doctor unless there is a symbol encoded for that. It also runs into trouble when the agent is asked to sit on the counter. Movement should be possible. However once movement becomes a requirement we can just create a new function and type signature that is less restrictive. This new function can still use these functions we are modelling now for dialogue.

Symbol graph

<<symbol graph>> \quadCleared To make sure the agent stays on topic we will make use of a symbol graph. This graphs gives connections to the symbols described in section A type signature approach. The meaning graph $G$ is a set of connections $c ∈ G$ where $c = (P, A, s_1, s_2)$, $s_1, s_2 ∈ \mathcal{S}$, $A \subseteq Λ$ is the set of agents that can use the connection, to prevent cases where the patient asks the doctor about his health problems. $P$ is the perlocutionary value set of the speech act, as introduced in section Dialogue tree. This is encoded in the edges because it’s not the meaning that causes these but the way you get to those meanings. In other words, being polite and then telling bad news causes different perlocutionary values than just telling bad news.

\cleared From this we can define a function that gets the allowed connections using a symbol and an agent from the graph: \[ G → a → s → \{c\} \] We can retrieve $a$ and $s$ from the current node we are processing in $D$. The result is a list of connections we can go to from that symbol. We can map a connection $c$ to a utterance $u$ by flattening the set of Actors $A$ in connection $c$ into individual actors, for each actor we can create a possible utterance $u$ from the information in $c$. From these utterances in turn we can create new dialogue tree options.

\doubleCleared The introduction of the symbol graph is probably the most radical change this thesis proposes. It moves chatbots away from the idea that responses are many to one relations always and opens up many to many relations. There are more advanced techniques such as owl available, we discuss these in section More advanced learning. We didn’t use that because we thought the step from ontology to language would be to difficult to finish in time. The symbol graph provides a good middle ground, in which it’s relatively easy to implement but offers enough freedom to encode personality in as a process. Note that this approach fits into the information state transitions discussed in section Dialogue systems.

Function attitudes combined

<<Composing types>> \doubleCleared The first thing a programmer may think of when trying to combine behavior is functional composition. The most important requirement for this to work is that the input type and output type need to be the same of the two functions we want to combine. What is problematic however is that using functional composition in this way would make it impossible for function attitudes to inspect results of their auxiliary functions. This is an important feature we want to keep because if for example a judgement function is first in the order of functions and receives the user meaning it can’t do its job yet, more on his in this section Rational and irrational. Therefore we consider another approach.

\doubleCleared We considered storing the functions in a list and then let an external control unit decide which function processes next. However this would leave the control of the function being called outside of the control of the function attitudes, therefore personality wouldn’t play a role in deciding the function being called. It will also create another problem of deciding when a function is called. So to solve these problems we looked at another possibility.

\doubleCleared In this approach we will give $f_a$ another argument which is the next $f_a$. This looks like the following: \[ \left (\overset{next}{B → D → (B, D)}\right ) → B → D \overset{f_a}{→} (B, D) \] Note that the function in the next bracket has the same prototype as the codomain. A more compact way of representing this type signature is the following: \[ \overset{next}{f_a} → f_a \] In this case the next function can play an advisory role to the codomain. A unit function can be defined that produces empty sets as results for both believes and action. By unit function we mean the initial next function that does nothing and just returns the believes and dialogue tree.

\doubleCleared To illustrate the use of this type signature design more clearly we’ll sketch an example with the first two function attitudes of the INTJ type: \[N_i > T_e \] So to encode this as a function we start with the least preferred function attitude namely the $T_e$, however to let it play an advisory role in the $N_i$ function we first need to complete the next argument. Because it’s the least preferred function we just use the unit. Now the partially applied type of $T_e$ satisfies that of $N_i$ and we can use it as next. This methodology can be used for an entire personality type (all eight functions in some order). Also as an analogy we could say that we’re dealing with an intrusive linked list. The next argument is the next item in the list. Unit is the tail item of that list, which exists to provide a start point to create the data structure upon.

\quadCleared With this methodology function attitudes can decide themselves to consult the next type. Then they can inspect the result, and even the changed believe base to decide if it’s a good idea to use the result.

\cleared This architecture can be extended with the scale based Jungian models such as SL-TDI and PPSDQ by introducing a random choice for using the current or next function. However this becomes rather messy because we’re modeling pure functions, therefore we leave this as an exercise to the reader.

Applied to Jung

<<Rational and irrational>> <<Mapping to process>> \doubleCleared Up until now we modeled the type signature to have a dialogue tree as input and output. However we have not considered how children are generated and how the order is determined. If we look at the definition (section Jungian types) of rational and irrational, we can make a design decision about what these functions should do to the children. Rational functions are about making decisions therefore they should apply order to the children. irrational are about producing information therefore they should produce new children.

\quadCleared There are however some edge cases to consider when modeling this idea. Say the primary function is a rational one. It receives a dialogue with just the root node. Currently it cannot apply any order since the children list is empty. Luckily it can still use its next function, which is irrational (see section Jungian alternating functions).

\doubleCleared Another situation to consider is what to do when there are already children. Should an irrational function extend this list of children or go to some leaf node? Same question for a rational functions should it sort everything or just the children list on its respective level. At which level a function should operate is rather fundamental. We will discuss this level of operation in more detail at section Function ply depth, since this discussion is quite complicated and not important for the main idea of what rational and irrational ought to do.

\doubleCleared With this in mind we can still say these things about the conceptualized architecture: rational functions change the order of possible replies. irrational increase the number of children. So if we start with an irrational function it produces several related symbols to the inputted dialogue tree. The original symbol uttered by the user is the root node and the produced response symbols are the children. These then get inserted into the next rational function which modifies the order of the children. This continues until all functions in the personality had their chance. Finally the unit function just returns the Dialogue and believes without modifying them, which returns trough all functions from before that can still modify the result. This could happen if a rational function was the first function for example and didn’t have any choices available to decide upon.

Irrational as a process

<<irrational process>> \doubleCleared The irrational functions rely heavily on the symbol graph to create new children in the dialogue tree. This is under the assumption that connections in the symbol graph are always on topic.

\doubleCleared In the initial design of the $S$ and $N$ functions, we considered them in the following way: $S$ would be analyzing all available options rigorously in a forward chaining process, whereas $N$ would do backward chaining, starting at the goal and going trough some way points directly to the starting point.

\quadCleared This would translate into $S$ going several plies deep into the symbol graph before calling the $next$ function and returning the result, and if we assume that the $next$ function brings us closer to the goal we can use it as a heuristic to let it determine the direction for $N$. This of course doesn’t allow us to do backward chaining since there is hardly a guarantee that the $next$ function will bring us back to the origin, in fact we may get stuck in a loop.

\quadCleared Alternatives to the implementation proposed include the use of probabilities to determine appropriate responses. However this introduces a new problem of how to obtain the probability distributions. Machine learning could be used for this, but this raises the question: `Learn on what?’ Since the answer to that question is non-trivial, we consider such a solution out of scope.

\cleared We decided to use a more simple approach instead, $S$ would be options in breath, analyzing many details around it, and $N$ would be options in depth, just taking what first comes to mind and plan ahead on that.

Intuition

\cleared We can consider $N_i$ to be a depth first approach. Going several plies deep and at each ply consulting the $next$ function which step to take. $N_e$ on the other hand just takes the top $x$ of the current dialogue options and expands those, but then next step it will again consider the entire existing tree to find the best $x$ of each ply. This will of course be a much more shallow consideration than $N_i$, but also more broad. Which is the behavior we are looking for in both $N_i$ and $N_e$ (see section Jungian types).

Sensing

\cleared The $S_e$ function just receives all possible connections from the current meaning for several plies and then applies the next function on it. The $S_i$ however is more conservative and will only pop $x$ random meanings by default (the first $x$ connections), however it will construct its own connections of whatever the user said in response to the bot from previous conversations when at the same meaning (if it didn’t exists already). Whenever these connections are available they will substitute the random $x$. $S_i$ starts of kind off similar to $S_e$ but builds up over time. So $S_i$ acts as a learning function and $S_e$ as a possibility function which is what was described in the theory of section Jungian types.

Rational as a process

<<rational process>> \quadCleared In the current design the rational functions apply order to the children of a current dialogue node. Then once finished they will call the $next$ function on the most preferred child. This is to ensure all function attitudes can do some processing.

\quadCleared Please do note that although we have a game tree, we’re not dealing with a zero sum game. Dialogue is cooperative rather than competitive (see section Speech act theory). So doing an algorithm such as mini-max is out of the question. However we will borrow parts of it. Namely whenever a rational function finishing ordering the input set it will call the next function to do deliberation on the most preferred item.

\quadCleared We also model the rational functions as local optimizing functions. Only the current ply and maybe the next ply is considered, but not the entire tree. The primary reason for this is time constraints. However there is no reason why the entire available tree couldn’t be used.

Feeling

\quadCleared Initially we wanted to create two lookup tables for both feeling functions one. However this would be confusing to configure, the scenario creator would need to decide which values are external and which are internal. Campos however modeled feeling as a prediction of what the other agents will do. This describes $F_e$ rather well, $F_i$ not so much however. So we adapted and adopted that idea for $F_e$ and for $F_i$ we used the lookup table.

\quadCleared Both feeling functions $F$ use the perlocutionary acts to order the children. $F_i$ uses a predefined value set $h$: \[ p \overset{h}{→} i \]. Where $p ∈ \mathcal{P}$ is a perlocutionary value. This valuation is done by a lookup table on all available perlocutionary speech acts. $F_e$ tries to figure out what the conversation partners values by picking the perlocutionary act the other chose most. This is done by simply keeping track on how many of such speech acts the partner uttered and picking the that has been uttered most, if that one is not available we move to the next one. This is similar to fictitious play cite:brown1951iterative.

Thinking

\quadCleared Normally the $T$ function is about reasoning. There is little reasoning to do in our scenario except to get to the goal as soon as possible. The thinking functions $T$ do this without paying any attention to perlocutionary speech acts.

\quadCleared We could say that while feeling is concerned with perlocutionary speech act goals thinking on the other is concerned with symbolic goals. To model the goals of the thinking functions we will introduce the set of goals in an agents believe base $Φ$. Where a single goals $φ ∈ Φ$ consists of $φ = (a, s)$ a symbol uttered by a particular agent. Then there also exists the function that can compare goals with each other: \[φ_1 → φ_2 → b \] where $b ∈ \{ \top, \bot \}$ is a boolean, true or false that determines if the first goal is more important then the second. This function is asymmetric. Finally there is a function that determines if a goal is completed or not: \[φ → b\]

\doubleCleared Now to begin with $T_e$. It sees the conversation as the problem to solve. Therefore it will consistently choose speech acts that could help the partner to progress the scenario. It wants to put the partner in a position where he has almost no other options except to progress the scenario. If it encounters a child node with a goal $φ$ in it it will give priority to that. If there are multiple goals in the options the comparison function can be used to determine the most important one. Scenario progression is measured with help of scenes. If an option changes scene we assume it progresses scenario. This comes secondary to finding goals.

\doubleCleared To model $T_i$ however the most obvious solution would be to implement an axiomatic logic system. This is rather heavy on maintenance. Every agent would need to have their own axiomatic system to determine what to do for each node in the symbol graph. The only real solution would be to create this dynamically somehow, but this is out of scope of this thesis. Therefore we looked for an alternative.

\doubleCleared $T_i$ wants to help the conversation partner to analyze the problem according to the partner’s own internal logic framework, and to do this it wants to give as much options as possible to the partner. Therefore it will choose the speech acts that produce the most symbols for the partner. To do this it will sort the child nodes according to as much unique symbols as possible. Options that are goals still get precedence however.

Believes

\newlyCleared Now you may argue at this point we haven’t refined our types a lot, since the believe structure was defined as `Every possible believe’, which is basically analogous to `Anything you can think of’ or in a object orientated terminology: Object. Since the believes serve as input of our function and output of the function we may as well have said $Object → Object$. Of course the believes are not intended to be direct program output but rather just part of the mind. In other words, the believes are intended to be kept in a container whereas the input $D$ and the output $D$ would only be visible for the `outside world’. Still we want to refine believe to something which is less broad in scope. To do this we analyzed the Jungian functions and see what `extra’ information is required to function to perform their operations.

<<Believes overview>> \quadCleared We listed the function attitudes $f_a$ and their required information into table tab:fa-and-data. Therefore $B = (h, [u], Φ, G, a, G’, h’)$. For reference a symbol table of all introduced symbols is shown in table tab:symbols in appendix Symbol overview.

Functionrequired data
$T_e$The set of goals $Φ$, scene information and $G$
$T_i$The set of goals $Φ$, and $G$
$F_e$Utterance history [u] and $G$, self believe $a$, learned values $h’$
$F_i$Personal values $h$
$S_e$$G$
$S_i$Utterance history $[u]$ and $G$, and learned graph $G’$
$N_e$$G$
$N_i$$G$

\FloatBarrier

Practical changes

\doubleCleared In this section we discuss what influence testing had on the application. A big change was the way how turn taking operated discussed in section Turn taking, secondly the way we combined functions in section Composing types has some issues with depth discussed in section Function ply depth.

Turn taking

<<Turn taking>> \cleared In the naive approach we modeled turn taking with a simple round robin strategy. Basically the irrational functions would only consider options that change actor between plies. This makes it difficult however to model agents that hold long monologues, which happens for example to Susie in the case study (see section Susie the ENFP). You could do it by making just more symbols that hold all these utterances in one. However this is very inflexible. So to solve this problem we use alternation of actors whenever there is a tie between two options. So irrational would leave out the option that doesn’t alternate, and rational would prefer alternation when possible.

Function ply depth

<<Function ply depth>> \doubleCleared A big issue that turned up trough testing is at which level a function ought to operate. We have a two pass architecture, where functions can inspect the dialogue tree before passing it to the next function, but they can also inspect the result of the next function. The reason for the two pass architecture is explained in section Rational and irrational. Note that at some point in the reference implementation we stepped away from doing a pure next based approach and we re-introduced the list mechanism that was described in section Composing types. This was to allow drool rules to do inspection of the personality process in between function attitudes, for example to allow emotions to have their influence, or norms from the social practice. Partly because we have a hybrid approach of deciding the next function, and because we simply hadn’t worked it out for the pure next based approach we need to answer the following question: “How does a function know at which level in the dialogue tree it should operate?”

\cleared In a naive approach we tried an implementation where irrational functions will by default go down the left (most preferred) path to a leaf node and then generate more options, whereas the rational functions would sort the one layer above the leaf layer. This has a problem in that it would make a rational function in the first position of a personality the least relevant function, since in the first pass it does nothing and when going back it works at one level above the leaves. This is a problem because it should be the most relevant function instead of least relevant.

\doubleCleared Another approach is to use outside information to determine height. Basically we would put into the believes the order of functions. With this information and the dialogue tree we can calculate the right level to operate upon. A question that remains is: Should the rational function sort everything even options below its level or just options in its level? We decided that rational should sort its level and everything below it, because it allows the dominant rational function to have a more pronounced effects, whereas deeper level rational functions don’t have a direct effect upon the resulting dialogue tree. The `deeper’ less important rational functions only have a guiding role for irrational functions.

\quadCleared We could also let the rational functions sort the entire tree, and let irrational always extend the most preferred option. At first glance this idea would make order for rational functions irrelevant. Perhaps this isn’t the case however, since a lower level rational function would still guide which part of the tree get extended.

\doubleCleared To sum up, there are two methods of dealing with this issue. Firstly we can let rational functions sort everything, but then the deeper rational functions will become less relevant. Secondly we can let functions operate at a particular level based upon their position in the personality. We chose to do the latter, because we thought this would make earlier rational functions more influential. With this particular choice we can also make a decision about whether a function should operate at a particular height, or go downward trough the entire tree, we chose to let it go downward because then the personality will be more consistent in its choices if it wants to utter lower level replies. Note however that deeper rationale functions can still have effect by virtue of deciding which actions are generated indirectly.

\cleared To calculate an operation height, we need to know the function order, then the function itself and finally the height of the dialogue tree. Which results in the following: \[ [F_a] → F_a → i_{D_{\text{height}}} → i_{\text{operate level}} \] Where $F_a$ is the Jungian function, and $[F_a]$ is the personality, which consists of an ordered list of Jungian functions, $i_{D_{\text{height}}}$ is an integer which indicates the height of the dialogue tree and $i_{\text{operate level}}$ is the suggested operation height. To do this we group the functions in function attitude pairs, a rational and irrational function combined into an tuple. Of this we take the pair index of the input functions’ function pair, plus one if the second value of the pair is rationale, and the input function is rationale, otherwise plus zero

Consistency with theory

\cleared In this section we will explore if INTJ and ENTJ (MBTI) types would produce different actions by analyzing when the functions would act. We will only look at the first two functions because the argument holds for all functions after these. The first two function attitudes of INTJ are: \[N_i > T_e \] And of ENTJ they are: \[ T_e > N_i \]

\cleared What we would expect is that the $T_e$ and $N_i$ produce different results because of the order they have in the sequence. If we assume personalities only have these two functions, their respective differences are:

  • INTJ: At each ply $N_i$ will use $T_e$ to select the options generated.
  • ENTJ: $N_i$ will generate random options at each ply, which $T_e$ sorts recursively.

INTJ and INTP are different in attitudes, but have the same order. Since attitudes produce a different process by definition (see section Mapping to process), we can conclude that they will also behave differently.

\cleared Because we have behavior in dialogue trough order of function attitudes we can consider this system consistent with the theory MBTI presents. It is also consistent with Campos’ work because the functions are just units of processing that can be combined, and therefore we have personality trough a process. Thus this system can be considered consistent with the major sources of theory we used.

\clearpage

Architecture

<<Architecture>> \doubleCleared To combine the ideas discussed in section Jungian BDI with the existing program, some big architectural changes were introduced. For example the Alice bot was completely removed in favor of a new less tightly coupled scheme. The Drools engine has become the center of deliberation (which previously was the AIML). We will discuss these changes in this chapter.

\doubleCleared In this chapter we will discuss two architectures, the first is the architecture which is actually implemented, this deals with a single agent and the user. In section Implemented architecture, we will describe the main architectural changes between the current implementation and the original architecture discussed in section The serious game. After that we discuss the data structures in section Data structures. In section Initialization we discuss how the initialization of the program with help of the discussed data structures, we continue discussing the normal operation of the program in section Operation. In section Social practice support we discuss how social practice support can be added in the future and in section Multilogue architecture we do the same for a multilogue architecture, in which multiple agents can participate in the dialogue.

\quadCleared There are also several items we won’t discuss in this chapter because they haven’t changed, these include the protocol, and the Wildfly server and the unity client.

Overview

<<Implemented architecture>> \quadCleared A deployment diagram of the architecture can bee seen in figure fig:architecture-concept, where the dashed arrow means constructs, the solid arrow means uses and the other lines mean interacts.

#+RESULTS[d7ad4a538aa95d8a6289f8072fb1b615404a8cc0]: fig:architecture-concept img/uml/architecture-concept.png

\doubleCleared In figure fig:architecture-concept we can see the new deployment diagram. The server and client have mostly stayed the same, except for the bot. This has been completely replaced by a new system. The Alice bot used to be a file reader, pattern database and deliberation engine in one package. These concepts have now been split up, the file reader handles the loading part of the bot, after that it just inserts the symbol, pattern and connection databases into the Drools rule engine. The Drools rule engine then handles all deliberation, which can happen with the various components, such as personality emotions etc. Even the pattern matching is done by a drool rule with help of the pattern database. Since the file reader is no longer a part of the bot, it should be easy to add support for other data formats.

\cleared The biggest difference from the original architecture is the removal of distinction between Drools and the chatbot. In the new architecture we make all information in the files available to the Drools in a database. This is starkly different than the architecture used in section Server architecture. In the old architecture, the reply for a message is already determined before Drools had a chance to do deliberation. What’s even worse is that if the Drools want to utter a spontaneous utterance, then it had to be encoded in a string inside the Drools themselves. This means the strings facing the user are spread over both the AIML files and the Drools. This is confusing for new scenario creators since completely different folders have to be accessed to change the strings.

\quadCleared The changes proposed here, result in a much more simple architecture. Only one place does deliberation rather than two and only one API is used for generating responses, whereas previously Drools could generate replies, and the AIML bot.

\quadCleared Note that although we removed the ability for the bot to use AIML, it should be relatively easy to convert from the old AIML structure to the new format with help of a script. A proof of concept of this has been made of this in section Conversion script.

Data structures

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

– Linus Torvalds cite:linusbadgoodprogrammersquote

\quadCleared In this subsection we will discuss the main data structures used to implement the ideas from section Jungian BDI. We use class diagrams to accomplish this which are based upon UML cite:fowler2004uml.

\newlyCleared Before this is done we would like to point out several things to keep in mind. Firstly, we do not show everything precisely as implemented in the code, because that would clutter the diagrams. What we do model is all relevant information in structures and the relationship between those, following the words of Torvalds. Secondly, it’s better to think of the classes shown here as value types, in other words: The model part in the `model view controller paradigm’ cite:krasner1988description. Note that we use public fields in cases where immutability was possible. Thirdly we split up the class diagram into several to save space, the model has become rather big. However there exists a similar separation like this in the source code, the lower level components are in the salve_drools projects, whereas the higher level components are in the salve_personality package. The reason for this separation is that currently, the bot will simply not function without the low level components, but it can function without the high level components. Which in practice is done with the low level replies. Finally note that we use $[…]$ for lists and $\{…\}$ for sets in the class diagrams, to save space.

Low level diagram

\quadCleared In figure fig:droolclass the diagram containing the low level data structures used. These are the basic assumptions, or building blocks the implementation is constructed from.

#+RESULTS[9613fa0af1a6753d27b6e00f421e8f0f1145f62f]: fig:droolclass img/uml/droolclass.png

\cleared From figure fig:droolclass we can clearly see the importance of the Symbol structure in the application. Simply by counting the amount of structures that consist of it, and of course it is a very important structure because it is the building block that we use for information state transitions. As described in section Jungian BDI we map strings into symbols, and once the symbol graph is used to find a connected symbol, we can map symbols back to strings again. An overview of the relationship between the theoretic representation and the implementation for this class diagram can be seen in table tab:jung-class-relation-drool.

SymbolCorresponding Class
$σ$String
$s$Symbol
$g$PatternSymbol
$g’$Symbol=[fn:: The literal strings are used for back conversion, in combination with the =MatchedQueryDB described in section Before and templates]
$P$PerlocutionaryValueSet
$p$PerlocutionaryValue
$a$Actor
$u$Utterance
$c$Connection
$h$PersonalValues
$φ$Goal

\quadCleared Something that was thought about is how similar a Connection is to an Utterance. Except for the instant field, they are the same (note that the informative field of utterance is the same as the to and restrictedo fields of connection). However their semantics are clearly different: A connection entails a possibility of an utterance, but it does not mean it will be uttered, whereas an utterance is a used connection, that became a realization. Therefore, we consider this type level distinction as correct.

\quadCleared These considerations become especially important when structures are essentially the same, as we can see with the Scene and Actor classes. The only thing they contain is a string. Even the field names are the same! Are we correct to treat these as distinct types? We argue yes because they entail completely different semantics, the Scene class is used to group symbols and patterns, whereas the Actor class is used to identify actors.

\newlyCleared The next question would be: Should we use an inheritance relation to make our code more DRY (don’t repeat yourself) cite:thomas2010orthogonality? For by example introducing an abstract class ANamed and letting Actor and Scene be extended from those. We argue no, because it introduces more complexity than that we would save on code reduction. It would also open up the possibility to use the implicit covariant relationship, resulting in functions that could accept an ANamed argument for example. As soon as client code starts using that, the single inheritance `slot’ Java provides is occupied forever, or at least until a major refactor occurs. Therefore we didn’t do this

Believes and dialogue tree

<<Believes and DialogueTree>> \quadCleared In figure fig:jungclass we can see the higher level structures of Believes and DialogueTree. Note that we significantly simplified all classes from section Low level diagram in this figure to save space.

#+RESULTS[ef07c4845eb64d8ba10a99e04f62f5ea95cfdad3]: fig:jungclass img/uml/jungclass.png

\quadCleared From figure fig:jungclass we can see the main clients of the low level drool package is indeed the Believes class and after that the DialogueTree. Believes provide the Jungian functions with bounded information about the mind of the chatbot as discussed in section Jungian BDI. In table tab:jung-class-relation-dialogue we can see the relationship between theoretic representation and that of this class diagram, excluding the ones discussed in previous section.

SymbolCorresponding Class
$B$Believes
$D$DialogueTree

\cleared The Believes structure is very peculiar, because it doesn’t represent a single idea or use case. Instead it’s just a combination of various elements that are required for the Jungian functions to operate. But none of the functions use all fields, so they get more `assumptions’ than they need, which is an architectural problem. The drool fact base and rule `when’ clauses have a mechanism for dealing with this as described in section Drools background. So an argument can be made to remove the Believes structure and replace it with the drool fact base and `when’ clauses. This hasn’t been done, because it would be a very invasive operation, currently the Jungian functions have the Believes structure in their signature. This can then be replaced by what they individually need, rather then what they as a whole need. With that change the personality functions could be flattened to drool rules, which would make the architecture even more simple.

\quadCleared The DialogueTree structure is however a whole other beast. It provides a well defined structure, and some utility methods that make tree navigation much easier. These methods aren’t shown in the figure because their type signatures are rather big.

Db package

<<db package>> \doubleCleared In figure fig:dbclass the databases are shown. This is a sub package of the model. The database is an immutable hash map. It also provides some extra Java 8 features, such as returning an Optional rather than a null reference as get method. The concrete implementations of database can add extra behavior once the type value of the generic parameters is known which is done by connection database for example.

#+RESULTS[add574f335f862e5e54dc28214bdc3d97f659be0]: fig:dbclass img/uml/dbclass.png

\quadCleared SymbolDatabase is the first database constructed during the initialization phase. From this the other two databases can be more easily constructed since they can lookup symbols in the SymbolDatabase, rather than worrying about construction of new ones. This class is the realization of $\mathcal{S}$ from section Jungian BDI.

\cleared PatternDatabase can store patterns per Scene. There are two constructed of these, the first one constructs the patterns that are in a scene, and the second one constructs patterns that are of scenes where the current scene is connected to. For example if there exists a connection form a symbol in scene $a$ to a symbol in scene $b$, the patterns from the symbol in scene $b$ are stored in the key of scene $a$. This second database allows scene transitions to occur. To construct this second database a connection database is required however.

\cleared ConnectionDatabase is a database that stores a connection set from a symbol. This class is analogous to the symbol graph $G$ from section Jungian BDI, it is used to determine what the bot could say, and what it thinks its speech partner can say. This database has a special method named createDual which is used to create a connection database where all the connections are flipped. This is used to create the second pattern database, making looking up the required patterns much easier.

Jung in Java

\quadCleared To implement the theory presented in section Jungian BDI, several issues had to be overcome. First of all Java has no native support for doing partial application. We worked around this Issue by introducing a structure that contained the arguments of the $f_a$ function described in section Mapping to process. The structure is called JungFuncArgs and can be seen in figure fig:jungjavaclass. The next issue was doing Functional composition, and although we can do this in Java with anonymous classes, we wanted to make the relation more explicit. The NextFunction and its respective field in JungFuncArgs is this explicit relation. Adding this field to the JungFuncArgs makes the functions a true endomorphism, although it deviates from the theory since the result now also has a next function. This also introduces an infinite creation sequence, there always needs to be a next function. To break this the UnitNextFunction was introduced. An argument can be made for using the null reference instead, however this is considered a bad practice cite:nullrefsarebad. Finally for testing purposes we needed to be able to inject other functions than the ones defined in the JungianFunction enum. Therefore the JungFuncAccessor interface was introduced. This allows unit test to check if the next function was called for example, but the architecture also becomes more extendable because of this.

\cleared Figure fig:jungjavaclass shows the elements required for Java to apply an $f_a$. To do this we first create a JungFuncArgs structure with its create method. Then we insert the Jungian functions we want to apply. This is a list of elements of the JungianFunction enum, these elements aren’t shown in the figure because they’re just the abbreviated names of the Jungian functions, for example $S_e$ for extroverted sensing. The insertNextFuncs returns a new JungFuncArgs object with the inserted next functions, these next functions are not evaluated. Also note that JungFuncArgs is an immutable object, so the result of the insertNextFuncs needs to be used. To apply the function we use applyNext(), which returns a new JungFuncArgs object with the resulting values.

#+RESULTS[726a09e81b64e8427cef8d44efb090848628fcc6]: fig:jungjavaclass img/uml/jungjavaclass.png

Before and templates

<<Before and templates>> \quadCleared After the personality was implemented, we wanted to bring the bot up too feature parity with the Alice bot. To do this several new data structures had to be introduced which can be seen in figure fig:templateclass.

#+RESULTS[9369d9064d088a03fc53246fb107cb2f5775046f]: fig:cache notemplateclass img/uml/templateclass.png

\quadCleared We can see from figure fig:templateclass that the consumers of these extensions are the Symbol class, the Utterance class and the Connection class. What also can be deduced is that the before extensions was probably a lot easier to realize than the template extension, simply by counting the amount of classes it introduced and modified. Whereas the template required the modification of at least three existing data data structures, the before only required to modify the Connection.

\quadCleared So the before class is self recursive, something which we’ve seen earlier in the DialogueTree class for example, however this is just an optional self recursive relationship. What it does is lay a restriction on Connection, the Informative in the optional Before has to be uttered before this connection can be used. See section That tags for a more in depth explanation.

\quadCleared The template system does something else. It introduces the ability to match variables from the regex and re-insert these as a template into existing symbols. This is explained in depth in section Star tags.

Support types

<<Support types>> \cleared Because we are working with Drools, we often use a technique of wrapping values into other types, to signify their progress in Drools deliberation. Basically we use types as labels to indicate progress. These types can either be defined in Java or Drools. If they are defined in Java, both Java code and Drools code can use it. If they are defined in Drools, only Drools code can use it. In figure fig:supportclassjava we can see the supporting types defined in Java and the relations they have with types defined in previous sections. We can see the types that are defined in the dialogue Drools package in figure fig:supportclassdrools and that of the personality specific Drools in figure fig:supportclassperson.

#+RESULTS[f789c4bb26dece3f3c667895afb3d407f463bdc0]: fig:supportclassjava img/uml/supportclassjava.png

\quadCleared The classes described in figure fig:supportclassjava have the primary function of starting the deliberation process. With UnparsedUserUtterance the initial utterance is inserted, and with ParsedUtterance it is translated to an understood symbol list. With these symbols the CaputerMatchDB is stored, which is later used to create an Utterance from. This isn’t done immediately because the Believes structure is required to create the utterance. We for example need to know which connection was used to get to this point in the conversation to figure out the PerlocationaryValueSet.

#+RESULTS[a688b910e5ada103f1a84bfa09d6eaee207c0d0b]: fig:supportclassdrools img/uml/supportclassdrools.png

\cleared By studying figure fig:supportclassdrools we can start to understand what is going on inside the Drools. We can for example see that a distinction is made for when a result matches an in scene pattern or a neighbouring scene pattern. These structures are of course there to do scene switching. We can also see that to create a reply we need to have a QueryDatabase. This is the result of the template match searched in the utterance history.

#+RESULTS[b074494c2edcbfd3dacf2340a12faa839b869329]: fig:supportclassperson img/uml/supportclassperson.png

\quadCleared In figure fig:supportclassperson we can see the drool defined PersonalityProcess. This structure tracks traversing the Jungian Functions. We manage this inside Drools to give other rules the opportunity to inspect the deliberation process while it’s going.

\FloatBarrier

Initialization

\quadCleared Dealing with cyclic immutable data structures is a problem. If we were to store the connections in the nodes, and a cycle would occur, updating the first node would invalidate the second node. A way of working around this problem is by letting the connections point to an address of the node, rather than the object itself. Another way of working around such a problem is having a mutable, cooking phase, and after that make the object immutable cite:zibin2010ownership. This is in essence what we do with the Database structure. We construct its data first with a standard java HashMap, and once this is complete we wrap this into the Database class. Which makes a shallow copy and has no API for mutation (see figure fig:dbclass).

\cleared This initialization problem is the reason why we chose the order of initialization shown in figure fig:initjung. The cyclic structure we want to create is the symbol graph $G$. So we start with the nodes in the graph, which are the symbols by constructing the symbol database. All symbols are constructed and put into the symbol database with as key a string containing the scene name and symbol name.

\doubleCleared Once we have the symbol database we can use it to create connections from it. We can see in figure fig:dbclass that a connection database consists of symbol key values leading up to a set of connections. In figure fig:droolclass we see that connections consist of a symbol object it’s going too with some additional values. To get the symbol values we just do a lookup in the symbol database, we know the key value from the file system and the _connections YAML file. In an initial iteration the symbol object wasn’t used directly as key, instead the symbol scene name and symbol name string were used. However using the symbol directly is more type safe and ergonomic. The other values of the connection class can be determined by the YAML as discussed in section yaml connections. An alternative approach would have been to store connections inside the symbols themselves, however this would make it impossible for the symbols to be immutable.

\cleared Finally the pattern databases are constructed. Patterns were after reading the symbols already put into a HasHmap, with as key the symbol and as value the set of patterns. So the only things that needs to happen for the in scene patterns database is to group them by scene. For neighbouring scene patterns however connections are required as discussed in section db package. This is why we postpone constructing these to the end.

#+RESULTS[45847c9f9bc829b639d91ab38fcd555cb9d9c944]: fig:initjung img/uml/initjung.png

Operation

\quadCleared To understand how the operation of a bot works, we can look at it from the point when a message is received and walk trough the steps it takes. An outline of this process is giving in the figure fig:insert_meaning. Together with the outline and the figures defined in section Support types, we can quite precisely explain what is going on.

#+RESULTS[ba2ef7b0333cc8277765f73cc81a4e7ac3846b44]: fig:insert_meaning img/uml/insert_meaning.png

\doubleCleared This operation is starkly different from the one presented in section user utterance processing, particularly if you compare the activity diagrams in figure fig:utterance-proccesing with figure fig:insert_meaning. What we can see directly by comparing these is the change in swimming lanes cite:planumlswimminglanes. The Alice swimming lane has been removed completely, and in its place we’ve got Drools, which has become the center of the application. Then the Personality swimming lane was introduced, this is of course in light of this thesis.

\doubleCleared Since these activity diagrams are quite detailed in their description of what is going on, we made an overview of the key changes in the state diagrams presented in figure fig:state:aiml and figure fig:state:yaml. In the new architecture, everything happens inside Drools. Only technical things such as dealing with the protocol and setting up the connection are handled outside Drools. This makes it impossible to bypass it, and it also opens up more space to do high level deliberations. Finally since PatternMatching is just the execution of another rule, we’re not just limited to just pattern matching schemes in figuring out what the user said. Alternatives approaches are discussed in section Replace regex.

#+RESULTS[91c67cdcbc4fe5fd0a81ff9cd72c7eddf5ea00be]: fig:state:yaml img/uml/figstateyaml.png

\quadCleared To ensure rules are executed in a particular order we often wrap and unwrap required data into types, as explained in section Support types. For example the initial user utterance gets wrapped into an UnparsedUttarence type, before it’s even inserted into the Drools. This type can be seen in figure fig:supportclassjava. We could have just inserted a string and not created the type, but the reason for doing this with the initial string is to make it explicit: This string needs to be parsed.

\quadCleared So in Drools we can match on this type (see section Drools background). Which we do in the next step, parsing this string with pattern (regex) matching. This is actually the $σ → s$ operation from section Narrowing the model. To do this we use the pattern databases from figure fig:dbclass, on which we use the active scene as a key (which is stored in the fact base) and then just match against all from the resulting set, this results in the ParsedUtterance type which can be seen in figure fig:supportclassjava. This type then gets inserted into the fact base to continue the process.

\doubleCleared The ParsedUtterance then gets transformed into a PreProcessed type. During this process the duplicates matches are removed. Each element in the ParsedUtterance list gets individually inserted as a PreProcessed type into the fact base. The reason for this in-between step is because we don’t know how to handle multiple matches. So we just insert every uniquely matched item. In contrast to the initial approach where only the first match was used, this approach is more flexible. It allows the bot to form opinions about utterance where it doesn’t necessarily wants to reply upon. For example if it asks the doctor “How are you doing?” the answer of “I’m good, how can I help you?” or “how can I help you?” should be treated differently. It now can also give multiple answers to longer user utterances. However the disadvantage is that sometimes the bot will give more replies than desired.

\quadCleared As a first priority the low level reply rules can be fired. What they do when fired is removing the PreProcessed type, so that the high level rules don’t get a chance to fire. This is modelled in figure fig:insert_meaning as an if else branch, which is true in practice, but no concrete if else structure is used. Drools has support for setting priority of execution in rules, which was used for this.

\doubleCleared It should be noted that at the point of quick reply personality could also be at play. For example people could have alternative ways of pronouncing the response. Thinking people may for example respond with a confident yes, whereas feeling people would say it by default in a more doubting tone. We have not taken such variations into consideration.

\cleared The high level processing executes if there is still a PreProcessed type available, in other words no low level replies were executed. We create the initial DialogueTree, and remove the Believes from the fact base and put these believes into a PersonalityProcess which can be seen in figure fig:supportclassperson. The reason for removing the believes base is to prevent concurrent modifications, by removing the Believes structure, rules that use it are no longer executed. To create a PersonalityProcess, a Believes structure has to be available. In this Personality process we also add the JungianFunction list, these are the functions that are extensively described in section Mapping to process, and its Java adaptation is described in figure fig:jungjavaclass. With this list it is determined which function should be executed next upon the DialogueTree and Believes.

\doubleCleared After there are no more functions in the list, we know we are done. We move to the next step where we get the reply from the DialogueTree. This is an Utterance structure, if this Utterance is the same as the self field in the Believes structure, we send the reply by wrapping the utterance in a Reply type. If we don’t send a reply, we insert a FinishedProcess type. If we do send a reply we reinsert the selected Utterance as a PreProcessed type. These types can be found in figure fig:supportclassdrools.

Social practice support

\doubleCleared Currently our support for social practice is rather limited. It was not a core goal of this thesis to support this, however it was important that in future work it should be possible to add this. This was a reason to keep using a rule engine as core deliberation mechanism. We tried to make the deliberation process as transparent as possible to the rule engine.

\quadCleared Because this entire process is implemented in Drools, and we use types to track progress. It’s relatively easy to add other rules that can modify the process, without changing the existing ones. Priority can be used to intercept a rule, as was done with the low level replies. Adding a more refined implementation of social practice therefore would be relatively easy. There exists already some support for the social practice in Drools, for example the scenes logic, but this is not complete. Better support can easily be added by adding more rules and tweaking with priorities.

\quadCleared Besides using extra rules to add support for social practice logic, for the personality part of the thesis specifically there is another possibility. They can be wrapped in a social practice function, that analyzes the result of the personality function and then does social practice operations to the resulting DialogueTree or Believes. So based upon the social practice, and the personality function things may change.

Multilogue architecture

\quadCleared The architecture presented in section Implemented architecture is for a dialogue game. However a social practice does not put limits on the amount of participants, so what we really want is a multilogue architecture. Since the presented architecture in section Implemented architecture is relatively close to that we shall discuss here how to finish it. What we therefore will discuss in this section is the required changes to make it a true multilogue architecture, and thereby making it easier to implement social practice theory. Sadly there was no time to do the actual implementation of such an architecture. A deployment diagram of this architecture can bee seen in figure fig:n-agent-arch.

#+RESULTS[94d7551a55c1eccb6e27f58fb140524484d49d94]: fig:n-agent-arch img/uml/n-agent-arch.png

\doubleCleared If we compare figure fig:n-agent-arch with figure fig:architecture-concept from section Implemented architecture, we can see several large changes. First of all the scene and scenario are now split of from the bot Drools. The reason for this is discussed in section System vs agent believes, but it is basically to separate the system from the agent believes. Also note that there is just one system, but there can be multiple bots. Each of these bots has its own file reader, pattern database, and symbol graph. We introduced the social practice component as a way for the bots to predict how the scenario will go. The score component has direct access to the bot facts to evaluate how the user is doing, for example by analyzing the bots’ emotions.

System vs agent believes

\doubleCleared What is required of the Drools is that we make a separation between the multilogue system and agent believes. A good step in this direction is the Believes structure, which groups most agent thoughts, at least those used by the high-level system. Although it should be noted that the Believes structure itself also has problems, this is discussed in section Believes and DialogueTree, but the gist of it is that it’s better to replace this structure with a Drools fact base. Since it has a self field however, it could be used to identify an agents’ believes. In other parts of the current architecture this is not the case at all. For example the PatternDatabase are just plainly inserted into the fact base. Which means we can’t identify who’s patterns these are.

\cleared The naive solution is to just mark every fact with a self field. Aside from the fact that you now introduce boilerplate code cite:lammel2003scrap, this has another more serious problem, it grands the ability for agents to read each others minds. Since every believe structure, and thus agent, will live in the same fact base. This is of course not desirable, it would defeat the entire purpose of a multilogue system, at least for the agents.

\quadCleared So what we present in figure fig:n-agent-arch is a different approach. What we do is separate the system from the agent believes. The system will be in the sys.drools engine, whereas the bot will be in the bot.drools. These are separate KIE runtimes, but the system has access to the bot.drools facts so it can do scoring and actually send responses for the bot. The server can then have multiple bot instances. In these instances not every fact has to be marked since they have their own fact base anyway. The only thing that needs happen is a self fact needs to be inserted, or the Believes structure could be used for that, if it is kept around.

Identifying speaker

\doubleCleared Another big issue is figuring out which agent(s) is being talked to by the user. There has been some research on this subject, for example using hand coded selection mechanisms cite:klotz2011engagement, and statistical mechanisms cite:keizer2013training.

\quadCleared Although both these approaches are good options for robots, we are dealing with an application, in which we can cheat to get basically nearly 100% correct selection. We can simply modify the user interface, to let the user select which agent he talks too. Then the only thing that needs to be done is modifying the protocol so that the selected agent(s) get the message. You can of course extend this to select groups of agents, or make the selection based on some kind of abstraction, such as the distinction between whisper to an agent or shout to an agent.

\quadCleared In the data structures however a more structural change needs to occur, namely in both the connections and the utterances. The Utterance class need to be extended with to who the utterance was said, and the Connection class needs to get an additional restriction on to whom this connection can be said too. These definitions can of course quickly get out of hand, especially with larger groups, and therefore it would be wise to define some kind of role mechanism, for which solutions exist cite:sandhu1996role.

Practicalities

\doubleCleared Then there are some practicalities to consider, that are more at implementation level. For example replies should be timed, so that the user won’t see suddenly 200 lines of chat messages between two of his conversation partners. This is relatively complex to do because with multiple bots and doing timed reactions some kind of communication needs to occur between the bots. This is probably a task for the system, but it could also be considered a part of the social practice. Do note that these timed replies should be interruptible by the user. A different way of dealing with this is just preventing the scenario from continuing at certain key points until a user reaction occurs. Deciding which approach is the best is a matter of experimentation.

\doubleCleared Then it should also be noted that the scenarios of the bots should be specified differently. At least for parts of it, while other parts should be shareable. So the YAML files should be specified distinctly per bot, the Drools files distinctly per bot and there could be a mechanism to share these.

\clearpage

Replacing AIML

<<From strings to meanings>> \quadCleared In this chapter we will discuss AIML in detail, we will explain why AIML doesn’t fit our requirement. Then we will start analyzing the structure of AIML and see how we can alter it to make it fit our requirements better. After that we will introduce a new modeling system, that is more succinct and flexible then AIML. Finally we will present a script to convert from AIML to the new format.

AIML issues

\quadCleared Originally, AIML was used for mapping user input to a reply. However, as explained in section Architecture, AIML has some problems for our particular use case. The major two issues are:

  • No way of giving Drools space to do deliberation aside from updating the scenario.
  • No way of accessing the knowledge base from inside Drools.

A relatively simple solution to both of these would be to use an XML parser to load AIML into a data structure and insert it into Drools, however this won’t solve the core of our problem: The way AIML models a conversation makes it hard if not impossible to list possible actions for an agent at a particular point in a conversation, therefore no true deliberation is ever possible as long as AIML is used. As we will see in the coming paragraphs, trying to adapt AIML to fit the requirements will transform AIML into something else.

\quadCleared To give a good intuition of this issue, we use an example. Listing code:aiml-std-cats shows a piece of dialogue modelled in AIML. This is a pretty standard piece of AIML, no surprises there. Patterns are used to identify user utterances and attach responses to them. We created a deployment diagram of the situation seen in figure fig:dep:aimlcats, which removes the syntax, so that the situation is more obvious.

\doubleCleared What we can see is that if the user says “Hello” then the bot will reply “Hi”. So what we have here is a mapping function from $σ → σ$, where $σ$ is a string (see section Narrowing the model). The issue is that once Hello is matched, the answer must be Hi. S-AIML extends this with adding drool tags, but these are inside the template tags and therefore cannot truly get out of this relationship. Unless they were to replace the entire content, in which case AIML is no longer used as knowledge representation anyway.

\quadCleared We’re also not modelling the entire conversation. There is no way for the bot of knowing that his Hi utterance, could be followed up reasonably with the question “How are you?” for example. Therefore there is no way for the bot to plan ahead in the conversation, or have any kind of variations in these plans. This is of course a problem, because we imagine personality as variations in a process, or plans (See section BDI + Personality).

<aiml>
    <categroy>
        <pattern>
           Hello
        </pattern>
        <template>
           Hi
        </template>
    </categroy>
	  <category>
		  <pattern>
			  How are you
		  </pattern>
		  <template>
			  Not doing too well today.
		  </template>
	  </category>
	  <category>
		  <pattern>
			  How * you
		  </pattern>
		  <template>
			  <srai>How are you</srai>
		  </template>
	  </category>
</aiml>

#+RESULTS[0889516e6ef32d64003ace8ae606a81cc01e305d]: fig:dep:aimlcats img/uml/dep:aimlcats.png

\quadCleared There are also some other small problems, which aren’t really that important for this thesis in particular, but worth mentioning. Such as with AIML one has to use the AIML based patterns defined by the standard cite:aimlspec, there is no way to use full regular expressions, or statistical methods. Another issue that we can’t access encoded utterances directly, so from Drools there is no way to do spontaneous utterances unless they’re hard coded strings. Finally, since Drools can be skipped all together (see figure fig:state:aiml), the bot could have amnesia about certain utterances, to prevent this every template tag would need an insert tag, which is boilerplate code cite:lammel2003scrap.

\quadCleared What needs to happen is either to either modify the Alice bot and AIML to work fundamentally different, or outright replace it with something else. We chose for the latter, we did so by first carefully analyzing AIML and deciding which parts we want to keep, and which other parts we wanted to remove or change. The next sections will discuss the thought process to a new representation.

Analyzing AIML

\doubleCleared What we want to do is create a mapping function $σ \overset{g}{→} s$ (see section Narrowing the model). In our first attempt we will modify AIML to do this. AIML is primarily a case based reasoner. It will match on predefined strings or patterns and then `say’ the string that was attached to the pattern. So we can use AIML to match user input, but the language has to be modified so that instead of producing a reaction, it will indicate what the symbol is that was matched. An example of these changes can be seen if we compare the listing code:aiml-std-cats from the previous section with listing code:aiml-symbols. The new deployment diagram can be seen in figure fig:dep:aimlsyms.

<aiml>
    <categroy>
        <pattern>
           Hello
        </pattern>
		  <symbol>
          Greeting
		  </symbol>
    </categroy>
	  <category>
		  <pattern>
			  How are you
		  </pattern>
		  <symbol>
          StatusInquiry
		  </symbol>
	  </category>
	  <category>
		  <pattern>
			  How * you
		  </pattern>
		  <symbol>
          StatusInquiry
		  </symbol>
	  </category>
</aiml>

#+RESULTS[106f5543883a89c0ef55c28146a484e5a0abd7cd]: fig:dep:aimlsyms img/uml/dep:aimlsyms.png

\quadCleared These changes remove the reactive nature of the chatbot, no longer do patterns indicate what to reply to, but instead simply what they are. This example can’t be functional of course, since the symbol graph hasn’t been introduced (see section symbol graph), so there are no replies. However we can at least use these to to create the symbol graph from.

\quadCleared With this we almost have solved the first problem of not being able to do true deliberation. Of course we can’t make a reply of this yet since we still have the second problem to deal with, how to access information stored in these symbols. In other words, dealing with the $g’$ function, this is what the next section deals with.

Symbol to string

\doubleCleared The next step is to consider how we go from symbols back to strings. What we assume is that the agent already found a symbol to utter, for example the status inquiry. This string from a status inquiry is already available in AIML, they were called template tags. We just need to separate the literal strings from the catch all patterns as can be seen in listing code:ailm-grouped-literal. In this listing we renamed the template tag to literal, because the name `template’ is very generic and we have already used it for another system discussed in section Before and templates and Star tags. They function the same: Provide the string to utter for that particular category, in other words the $s \overset{g’}{→} σ$ function (see section Narrowing the model).

\quadCleared In deployment diagram fig:dep:aimlliters we can see how this works in memory. Patterns point to symbols, which have the literal utterance available to them. Since the names of symbols are not the same as the literal content, we can use terse descriptive names for more verbose content. Such a property is useful for referring to the symbols from inside the drool engine.

<aiml>
    <categroy>
        <literal>
           Hello
        </literal>
		  <symbol>
          Greeting
		  </symbol>
    </categroy>
	  <category>
		  <literal>
			  How are you?
		  </literal>
		  <patterns>
			  <pattern>How * you</pattern>
			  <pattern>How are you *</pattern>
		  </patterns>
		  <symbol>
          StatusInquiry
		  </symbol>
	  </category>
</aiml>

#+RESULTS[8f9d88e8099c1ee4b136d0f0b0d17eb31a02a660]: fig:dep:aimlliters img/uml/dep:aimlliters.png

\quadCleared We can make the syntax from listing code:ailm-grouped-literal even more terse. Observe how one category always will have one symbol tag. If we were to extract the value of this tag and use it as a filename, we can ensure that each symbol is only declared once. Then we can also assume that the AIML tags and category tags are implicit. This results a terse definition as can be seen in listing code:aiml-terse. This doesn’t include the Hello code because that was part of another symbol, and therefore another file.

<literal>
    How are you?
</literal>
<patterns>
    <pattern>How * you</pattern>
    <pattern>How are you *</pattern>
</patterns>

\doubleCleared However the observant reader will see this isn’t valid XML and by extension AIML, since XML requires a single document root tag. It does specify what we want, and it does so very tersely. Since we are changing the semantics of AIML drastically we may as well use a more terse data format in which such a definition is legal. In the next section we will analyze some possible candidates.

XML vs JSON vs YAML, vs TOML

<<xml vs everything>> \newlyCleared All these languages are standards cite:jsonspec,yamlspec,xmlspec,tomlspec. However there is a major difference between XML and JSON or YAML, and that is their intention. XML is a markup language, whereas both JSON and YAML are data formats cite:yamlvsxml. What they all share is that they are supposed to be both human readable and parsable by a computer program.

\quadCleared So what we mean by human and program readable is that with relatively little effort, a human or program can understand what’s going on. Unlike say a binary format, which first needs to be parsed by a program before a human can understand it (or with great amount of effort). Alternatively unlike a human document, such as a book, a computer program needs to do lots of effort to extract information from that, whereas a human can just understand it `naturally’.

\quadCleared Markup languages provide a nice middle ground between human readable and program readable. XML does this by inserting tags (metadata, which are usually just annotated words), that gives meaning for the program, so that authors can focus on the structure and content of the document cite:coombs1987markup.

\quadCleared In AIML however, no document is constructed. It’s not a story with a lead, middle ground and conclusion, it’s more like a key-value pair database or big configuration file. So since XML was intended to be used for inline document markup, We will argue that there are better alternatives that focus on key-value based configuration in particular, such as YAML, JSON or TOML.

\quadCleared JSON is by far the best known format of these three remaining contenders. However JSON has a few significant disadvantages, for one it doesn’t allow comments and it is quite strict. For example a common acceptable mistake is to have an array with a trailing comma like: [1,23,4,]. This is an error in JSON cite:jsonconfig, while it’s relatively easy for a program to notice this is erroneous and therefore correct it. The syntax of JSON can be also more terse, which is shown by both YAML and TOML. Because of these reason we looked at the other two contenders.

\cleared The reason for choosing YAML over TOML is that YAML is stable, whereas TOML hasn’t reached stabilization yet cite:tomlreadme. Although the argument TOML has over YAML is that YAML is much more complex, and can in certain cases be not as human readable cite:yamldisatvantages. If TOML were to stabilize, it’s probably better to move to that format instead. Its instability means that the author thinks the representation may change. Therefore currently the best choice is YAML. It’s relatively easy to move between these standards, if they’re stable, as is shown in section Conversion script. Therefore a possible future move from YAML to TOML should also be easy. Note that because we separated file reading from the main bot we could even support multiple data formats (see section Implemented architecture).

Using YAML

\quadCleared It was decided conclusively to use YAML instead of AIML for symbol representation. How these symbols are represented in YAML can be seen in listing code:yaml-symbol. This is only a syntactic change, therefore no deployment diagram is made of this.

\quadCleared Rather than having a literal tag open and close to show what the literal is, YAML uses a key value structure. This key value structure is either a dictionary (in Java HashMap), or a class (see section Loading yaml). Lists can be indicated by using dashes in front of each item. Note that we still use the idea of having one symbol per file, and the symbol name is the filename. Therefore no symbol item is shown in the example. Quotation marks =”=, are to indicate strings, for certain characters this is necessary, in other cases YAML does this for the author.

\doubleCleared Note that there are multiple literals to choose from in listing code:yaml-symbol. In the current implementation this is similar to using random tags in AIML. However as can be seen in section Low level diagram, this list of strings is just available to the implementation. Therefore social practice could use it for example, making the selection situational, and this selection could be influenced by personality.

literals:
  - How are you
  - "What's up?"
patterns:
  - How * you
  - How are you *

\doubleCleared We keep the pattern fields for legacy support. However it’s much more easy to just support regular expressions cite:thompson1968programming. The reason for this is that they’re part of the Java standard library cite:regexpattern. What we do is transform AIML patterns into regular expressions, and then use the Java standard library to match the patterns. This will make the patterns more precise, and give less code to maintain, an example can be seen in listing code:yaml-regexes.

literals:
  - How are you
regexes:
  - "How ([a-z])\\w+ you(.*)"

\doubleCleared The example in listing code:yaml-regexes only matches a single word and allows for trailing characters. Note that the example in listing code:yaml-symbol would’ve also matched “How did this became you?”, since any character would’ve matched the star (not any but most characters, see section AIML stars). Regular expressions can be much more precise in specifying what a wildcard star is, although they are also a lot more difficult to learn and read. Therefore both methods will be supported.

Loading YAML

<<Loading yaml>> \quadCleared As explained earlier YAML key value pairs are either directly loaded into a HashMap, or into a class. We chose to use classes wherever possible because it provides more type safety. This is only possible if all keys are known before hand. Which it’s not in case of the template system for example, but in most other cases it is.

\quadCleared In listing code:java:rawsym the class where the symbols are loaded into is shown. The fields defined there can be used as keys in symbol files. Note that over some fields the user has no control, such as name and scene. Other fields such as literal need to have at least one value, although not shown in this structure. There are systems that allow declaration of fields and restrictions upon them to be shared cite:constraintmodelexample, which is more convenient for the user, but we didn’t do that in the interest of time.

public class RawSymbol {
	public String name; // defined implicitly by filename, user can't override
	public String scene; // defined implicitly by folder, user can't override
	public List<String> literals = new ArrayList<>(1);
	public List<String> patterns = new ArrayList<>(1);
	public List<String> regexes = new ArrayList<>(1);
    ...
}

\quadCleared In listing code:java:yamlread we show how one can load a YAML structure into a raw class. We also add some additional restrictions, we do not want to load multiple objects from a symbol file, although YAML supports it. This would break the name uniqueness guarantee the file system provides.

List<RawSymbol> syms = YapFactory.readAsYML(file, RawSymbol.class);
if(syms.size() > 1){
    throw new RuntimeException("Can't deal with multiple yml " +
            "objects in symbol file, please use different files " +
            "for symbols so that their names are gauranteed to " +
            "be unique, error in " + file.getName().getBaseName());
}

\FloatBarrier

Connections

<<yaml connections>> \quadCleared Now we’ve figured out how to represent our basic axioms, the symbols thoroughly, we can move on to make our model functional again. So what we have lost in the process are our update rules (see section Dialogue systems). In section symbol graph we model these as the symbol graph. However we have not made a syntactic representation of this, which will be done in this section.

Core idea

\quadCleared What we do with the symbol graph is re-adding the implicit connection from AIML between patterns and templates. Both patterns and templates have now become plain symbols (see section Mapping AIML). If you just have symbols the bot won’t know what to do when one of these is inserted without extra information. This is what we represent with connections. What sensible replies can we give if a symbol is uttered.

\quadCleared We will show how this works with help of an example. In listing code:yaml:simple we connected the symbols discussed in our original example from section Analyzing AIML. With these connections we can see the situation illustrated as deployment diagram fig:dep:connections, From this we can see that a greeting can be replied to with a greeting or with a status_inquery. Because we had multiple patterns leading up to these symbols, we now have multiple responses to multiple patterns. This means there is a choice now once a greeting is uttered, and choice opens up room for personality as a process.

from:
 - greeting
to:
 - symbol: status_inquery
 - symbol: greeting

#+RESULTS[e40a7a65df711e768167e64733acb2fb35e01334]: fig:dep:connections img/uml/dep:connections.png

Single file

\quadCleared Originally we just wanted to stick to the (implicit) AIML approach of connections, and add them within the symbol files as can be seen in listing code:yaml-connections-intrusive.

literal: Why are you here
to:
  - need_medicine
  - broken_arms
  - feel_sick

\quadCleared However we decided against such an approach. There were two reasons for this, the first one is that we found out that connections are much more complex than simple one directional links. They for example also need to contain perlocutionary values and be marked with which agent can use the connection (default being all agents). The second reason is a practical concern, it turns out that if you group all connections into a single file you can get a better overview of which connections are made. So you get a better sense of what could be said when. What we do now is a grouping of connections into their own special file.

\cleared Take as an example listing code:yaml:complex which is a connections file of a scene. In figure fig:dep:filedconns we can see a deployment diagram of that connections file. This is not a complete conversation of course just an expert of a larger model. Note that reading the code from listing code:yaml:complex is not much harder to understand than the deployment diagram. We can see that the connections modeled here are already quite complex, as this file grows in size the dialogue becomes harder to manage. Usage of scenes and tools in text editors such as searching become quite vital. In any case it should be less of an issue than in AIML since this syntax is more terse.

from:
 - greeting
to:
 - symbol: greeting
 - symbol: ask_reason_here
   restrictedo: doctor
---
from:
 - ask_reason_here
to:
 - restrictedo: patient
   symbol: need_medicine
 - restrictedo: patient
   symbol: broken_arms
 - restrictedo: patient
   symbol: feel_sick
---
from:
 - need_medicine
 - greeting
to:
 - restrictedo: doctor
   symbol: why_need
 - symbol: status_inquery

#+RESULTS[95cead6c9a6fb358accf6686cac4a2b62f2d9111]: fig:dep:filedconns img/uml/dep:filedconns.png

Actors

\doubleCleared A foreign idea to AIML is the notion of actor restrictions. Since AIML will always model from the perspective of the bot, there is no need for this. However because we model both bot and user, we do require this.

\doubleCleared To make sure certain strange situations don’t occur, such as the patient asking the doctor if the doctor is sick, we added actor based restrictions on connections. This is done trough the restrictedo key, which can be seen in listing code:yaml:complex. Currently however this implementation is rather limited, it only allows for an `any’ actor, which basically means any actor can say this, or a specific actor. This could be extended with some kind of role system cite:sandhu1996role.

\doubleCleared Note that because AIML does not specify actors, it can never be used on its own to model a multilogue system in. Although we make actors explicit not because of the desire to implement a multilogue system, but to make it possible to predict what the other actor will say from the agent’s perspective. Being able to eventually build a multilogue system on top of this is a nice benefit.

Scenes

\quadCleared In the S-AIML extension, scenes were used to enable and disable certain patterns. Unlike the topic mechanism of AIML which just gives preference, something from another scene wouldn’t be used at all. This is makes it easier to write dialogues, because we don’t have to worry about patterns from other scenes, so we can use more generalized patterns in our particular scene.

\quadCleared Although scenes aren’t necessary to implement the theory presented in section Jungian BDI, it is necessary for eventual social practice support. It also makes this representation much more modular. The part were scenes are actively used is in section db package, patterns are grouped based upon scene in the PatternDatabase.

\quadCleared The way we represent scenes is rather simple. We use directories as scenes, all the symbols within a directory are in that scene. Connections are implicitly assumed to be between symbols in the same scene as where the connection file is in, unless stated otherwise, which can be seen for example in listing code:yaml-scene-example.

from:
 - status
to:
 - symbol: ask_reason_here
   scene: information_gathering
   restrictedo: doctor
 - symbol: good
   restrictedo: doctor

\quadCleared In listing code:yaml-scene-example we can see two connections being modelled, from the status symbol to ask_reason_here symbol that transitions to a new scene, and from the status symbol to the good symbol that stays in the same scene.

\quadCleared We break away from the idea of S-AIML that scenes are linear. We believe that scenes are a weakly connected cyclic graphs. Note that by cyclic, we mean there can be cycles, but there don’t have to be. So we can go back to previous visited scenes for example. It’s weakly connected because it wouldn’t make much sense to model scenes that can’t get to other scenes trough connections. Although there is nothing preventing one from doing so, the common sense reasoning is: Why would you model a scene that is inaccessible from the rest of your model?

That tags

<<That tags>> \cleared The `that’ tags in AIML have a rather unfortunate name. They require the bot to have said something before the current pattern can be used. Therefore in our YAML semantics, they are an additional restriction on connections. They appear in listing code:aiml-that-tag as an example.

\doubleCleared Although supporting this feature isn’t necessary to implement the theory presented in section Jungian BDI, they do allow much more fine grained control over the scenario. We therefore decided to also implement this AIML feature.

<category>
    <that>Why is doctor Aarts not here I am one of his patients.</that>
    <pattern>
        surprised you're doctor
    </pattern>
    <template>
        <insert packageName="scenarios.large.global" typeName="SentenceSpoken" />
        <insert packageName="scenarios.large.prehistory" typeName="BadAndLateExplanation" />
        I did expect him to be here, yes.
    </template>
</category>

\cleared `That’ tags act as an extra filter upon the category. Before this category becomes active, the bot first has to have uttered the pattern in the `that’ tags. In the new representation we can model such a thing too. To model `that’ tags we add an extra optional field to the RawConnections called `before’, with two required fields, `who’ and `said’. The actor is indicated by `who’ and `said’ indicates what was said. An example can be seen in listing code:yaml-before-field.

before:
   who: patient
   said: "why_is_docter"
from:
 - "surprised_your_doctor"
to:
 - symbol: "expect_him_be_here"
   restrictedo: patient   

\doubleCleared Adding the who field was necessary since we no longer model just the utterances of the bot, we needed to expend it by adding the actor who uttered the utterance. We also needed to think about when it was uttered, because alternation isn’t a guarantee in conversation (discussed in section Turn taking). What is done now, is to filter out the utterances from the person who is not the who in the before tag, and then take the latest utterance from them.

\cleared To surpass the AIML `that’ tags, we can extend this mechanism by making the RawBefore type self recursive with an optional field before of its own type. This is best illustrated with an example which can be seen in listing code:yaml-before-recurion.

before:
   who: patient
   said: "why_is_docter"
   before:
      who: doctor
      said: "imhe_doctor"
from:
 - "surprised_your_doctor"
to:
 - symbol: "expect_him_be_here"
   restrictedo: patient   

\doubleCleared The default value of the before field will be None. Which just means no additional restrictions. In this example making such an explicit definition won’t be very constructive. However since we need an identity (no-op) before value anyway for the default restriction, making a recursive definition isn’t a big extension.

\cleared The AIML tag specification never defined when a `that’ tag match would be active cite:aimlspechat. However it can be derived implicitly from the reference cite:aimleferencehat that it should always be on the previous utterance. We could add options for when an utterance was made, for example just now or any previous utterance. However in the interest of time we won’t do this.

\FloatBarrier

Templates

<<Star tags>> \quadCleared In AIML, star tags are template focused. They capture the content of a wildcard at a particular index and allow them to occur in the bots reply. An example can be seen in listing code:aiml-star-tag. This is a simple trick to make the bot more flexible, and since in AIML patterns and templates occur hand in hand, doing this is easy. In this system we have not such a close relationship (on purpose), and therefore it’s more difficult to implement.

<category>
    <pattern>
        name is *
    </pattern>
    <template>
        Okay, <star index="1" />. Can we get started?
    </template>
</category>

\quadCleared Although this feature isn’t necessary for personality per se, it’s a really important chatbot feature. It allows symbols to become more flexible, and connections more dynamic.

\doubleCleared To implement these in our new system we first need to analyze what star tags are. Then we need to figure out how we can implement this in our matching system, and finally we need to add a template method to our YAML representation. The data structures involved are discussed in section Before and templates. What is discussed in this section is the behavior and syntax.

AIML stars

\quadCleared The AIML standard specifies cite:aimlspec stars as a one based index scheme. Wildcards are defined as any string in $L(N)$ where $L(N)$ is all normal words. This would imply that it would not include spaces or other special symbols. Since this definition is rather vague we did some experimentation on the example from listing code:aiml-star-tag. We tried to introduce ourselves to the bot with various names as can be seen in table tab:alice-normal-words.

InsertedWhat the bot accepted
jap34! gee!@jap34
jap gee23jap gee23
jap_23_flap ddd dfadfjap_23_flap ddd dfadf
blah *. blahblah *
blah * ahahblah * ahah

\doubleCleared Quite arbitrarily some characters are accepted while others aren’t, Alice happily accepts an underscore but an exclamation mark is to much. There are several ways to improve this system. Such as trying to add context to what the star should be. In our example case we wanted to match on names, so we know that numbers shouldn’t be allowed, or at least that it would be highly unusual. Social practice and norms could help with these distinctions.

\quadCleared We already improved on the star matching system by using regular expressions cite:thompson1968programming, which would allow scenario writers to be much more precise in what they want to match. However we want to also be able to store what is matched and access it later. The java regex API already provides a method of extracting information from wildcards trough something called groups cite:regexgroups. An example of an regular expression that extracts data can be seen in listing code:regex:extract. So the problem is no longer one of extraction, but just about organizing that what has been matched, and putting it in a template.

literal:
    - "My name is paul" # what the bot would say if symbol used
regexes:
    - "My name is (?<name>.*)" # the matching mechanism, store wildcard into name field

Templates in symbols

\cleared To insert data into a symbol we need a templating mechanism. We found three template libraries in Java: Velocity cite:velocity, FreeMarker cite:freemarker and StringTemplate cite:stringtemplate. Because StringTemplate enforces strict model view separation, and therefore is much more maintainable and easier to understand cite:parr2004enforcing, we chose to use StringTemplate, over the other two options.

\quadCleared Using that engine we can define a naive way of writing a symbol as can be seen in listing code:naive-template-symbol.

literal: "Hello, my name is <actor.name>"

\cleared In listing code:naive-template-symbol there is a problem however, is it always the case that the current actor should be used if we use a query like “<actor.name>”? No because we can say something like: “Hey <actor.name>, can I borrow your pen?”. Therefore we should reconsider selecting such things at the symbol level. A lot of context information is not available in symbol files. The best we can do is give them a name and leave it at that, as can be seen in listing code:template-symbol-context. This won’t add any restrictions on the inserted value. It’s just a hole that can be filled up by an arbitrary string.

literal: "Hello, my name is <name>"
--- # another file
literal: "Can I borrow a <tool>"

\doubleCleared How do we fill these templates? The issue we had with trying to fill these in the symbols was the lack of context. Context is mainly provided by connections, if we know who is saying “Hello, my name is <name>”, we know what to fill in for the template `name’. In this system context is provided by connections. An example of how to do this is given in listing code:template-connection-fill, where the name is filled by using a previous utterance. We use the match label to identify which matched item needs to be extracted.

from:
- my_name_is_x
to:
- symbol: hello_x
  restrictedo: patient
  utterances:
    name: # the template name to fill
      actor: doctor
      symbol: my_name_is_x
      scene: introduction
      match: name # group name to extract

\quadCleared There are several important things to note about this implementation. First of all it’s a lot more flexible than AIML stars, since information can be retrieved from any previously uttered utterance, if a connection has a query that isn’t satisfied, it is not available. Another advantage over AIML is that regular expressions allow much more precise input sanitation than wildcards. This could enforce input that is only numeric for example. Which in turn can be used within Drools as a query. Finally we preform checks to make sure that symbols with template names only have connections leading up to them that satisfy the template names. AIML didn’t have to do this in the first place of course, since stars only acted per category.

\quadCleared A feature that is missing is retrieving drool facts from the knowledge base and inserting them into the template. However one can workaround this limitation by writing Drools for this, similarly to low level replies. A MatchedQueryDB can be constructed manually to fill with drool facts.

Automatic AIML to YAML

\doubleCleared AIML is a standard cite:aimlspec. Note that the spec says: “AIML shall be compatible with XML.”, and XML is also a standard cite:xmlspec. YAML happens to also be a standard format cite:yamlspec. With all these standards, it’s relatively easy to convert between them, because libraries exist for parsing the standard, and in turn for generating it.

Legacy AIML

\cleared An introduction of a new format is nice, but when this is done, all the work in the old format could become obsolete. This is obviously not desirable. There are several ways of circumventing this. First of all, one could add support of the legacy format to the code base. The second method is creating a script that will help along the way with conversion. We chose the second method because the first method will be much harder, as it will re-introduce the problems we had with AIML in the first place. The second method provides the user an opportunity to make their AIML comply to the new method. The script does it automatically for most frequent cases, however we still expect user intervention to test and complete conversion.

\cleared To make the conversion we need to point out some structural observations about differences between AIML and YAML. Firstly AIML works strictly from the perspective of the bot. There is no deliberation about what the user is thinking. Therefore we can’t model what we expect the doctor to say after a patient uttered something in the test scenario because this information isn’t encoded. You may argue that the mechanism which could be used for this are the that tags. But they are just an additional restriction on the pattern matching, see section That tags. Alternatively you count the injection of types (in S-AIML), but this isn’t a formal encoding in AIML itself, but rather a way of informing Drools what’s going on.

Mapping AIML

<<Mapping AIML>> \quadCleared What we can do is extract the patterns, and their respective literals into symbols. For example we have the following category in listing code:aiml-mapping. In this example there are in terms of YAML two symbols and a connection. The first symbol is pattern tag, the second symbol is the template tag excluding the insertions, and the connection is from the pattern to the template which is restricted to the patient. So from this example we can define the mapping result in listing code:yaml-mapped, with its respective file names in comments above.

<category>
    <pattern>
        How long * pain
    </pattern>
    <template>
        <insert packageName="scenarios.large.global" typeName="SentenceSpoken" />
        <insert packageName="scenarios.large.timelapse" typeName="DurationPain" />
        For a while now
    </template>
</category>
# for_a_while_now.yml
literal: "For a while now"
---
# how_long_*_pain.yml
literal: "How long * pain"
---
# _connections.yml
from:
 - "for_a_while_now"
to:
 - symbol: "how_long_*_pain"
   restrictedo: patient   

\cleared A lot of category elements simply mean to add a pattern to a symbol, for example listing code:aiml-srai-mapping. What we can do with the SRAI tags, if they exist, is simply checking if the symbol exists and then add the pattern to that symbol. If the symbol does not exists yet, we create it anyway, since the content of a SRAI tag is a pattern itself. In this case, we just add both the pattern and content to the pattern list.

<category>
    <pattern>
        How long * pain *
    </pattern>
    <template>
        <srai>How long * pain</srai>
    </template>
</category>

Type insertion

<<Caviats>> \quadCleared After the conversion is finished, the bot will mostly work, with the added bonus that the dialogue will be more readable. However there are some caveats, especially in the previously introduced variant called of AIML called S-AIML.

\cleared In S-AIML types are injected to track progress of the scenario. In contrast to the current scheme where the entire user utterance gets inserted and it’s up to Drools to make a symbolic understanding from it. To work around the issue of inserting types we actually have to generate drools in case of a particular symbol inserted, which then inserts the type specified by the insert tag. For this we can just use the low level reply mechanism, but rather than replying we insert the specified type. This will allow the original drool rules to still execute. An example of this can be seen in listing code:drool:generated.

rule "insert types when symbol how_long_pain was uttered"
when
	$pre:PreProcessed($symbol:utterance.what, $symbol.name == "timelapse/how_long_pain")
then
	log.info(drools.getRule().getName());
	
	scenarios.large.global.SentenceSpoken obj1 = new scenarios.large.global.SentenceSpoken();
	insert(obj1);
	
	scenarios.large.timelapse.DurationPain obj2 = new scenarios.large.timelapse.DurationPain();
	insert(obj2);
	
end

\cleared Something which complicates this is that attributes can be set trough JSON within the insert tags. This can be handled inside the Drools rules because the inserted types always have setters. So there could be java code generated for that. Although we haven’t done this in the actual implementation since this feature didn’t seemed to be used a lot and we expect from the user to do manual modification of the generated results.

Proof of concept

<<Conversion script>> \quadCleared To show that it is indeed easy to write a conversion script, with above restrictions kept in mind we made a proof of concept. This conversion script is located in the conversion folder from the root project of the git project. It is expected to be executed from command line and provides several command line arguments that are documented in the script itself.

\quadCleared The usage of the script can be shown by passing the help parameter to it. As can be seen in listing code:sh-conversion-script-help. There are some features missing from this script however. The help message will display which.

python main.py --help

\clearpage

Implementation

\quadCleared In this chapter we will discuss the specific personality implementation details. We will discuss how to setup a scenario, and how we tested our system. In section From strings to meanings a lot of implementation specifics were already discussed.

\doubleCleared In this chapter we will first setup a small case study of personality influence in section Personality influence case study. Then we will show how to model a part of this scenario in section Making a scenario, to show how the bot works and how to steer it. Finally we will discuss how we tested the bot in section Testing.

Personality influence case study

<<Personality influence case study>>

\newlyCleared To make the influence of personality more concrete, we make a scenario of a doctor appointment where each patient has different personalities. First we have Sander the INTJ, secondly Susie the ENFP and Chris the ISTP. This type selection will give a rough usage of most Jungian functions. In all cases the patients have the same problem, a back pain. The cause of this problem in all cases is a worn out back. After the dialogue we will also discuss the motivations for saying things the way they do.

Sander the INTJ

\newlyCleared First we should note the dominant and auxiliary functions of someone with an INTJ MBTI type. An INTJ has as dominant function introverted intuition $N_i$ and as auxiliary thinking extroverted $T_e$. We would expect these function to be most obvious in the dialogue (as discussed in section sec:types). $N_i$ mainly focuses on connecting ideas and extroverted analyses objects in the external world. Combined with each other we get a personality that focuses on getting to goals by analyzing the situation far ahead of time. This results in the expected dialogue which can be seen in table tab:sander-conv-doct.

WhoUtterance
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\newlyCleared Sander gives the doctor the information he needs to come to the conclusion he himself probably already had drawn. We could even expect him to ask for the medicine immediately, however since this could make the doctor question his motives (he could be addicted for example) he decides not to do this. The doctor however doesn’t go into the source of the problem. He just assumed the patient overstretched himself because he lifted something heavy.

Susie the ENFP

\doubleCleared As an ENFP, Susie has the dominant function of extroverted intuition $N_e$ and as auxiliary function of introverted feeling $F_i$. Therefore these functions should be most dominant in the dialogue. $N_e$ focuses on finding possibilities in situations and $F_i$ is a internal value based judgement function. Combined with each other they make a personality who has strong ideals and is enthusiastic about them. The expected dialogue can be seen in table tab:suzie-conv-doct.

WhoUtterance
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\newlyCleared We can now see a stark difference with the INTJ personality. First of all being dominated by extroversion, it was Susie who took the initiative. Secondly she directly asked for medicine, without thinking about the consequences but knowing she probably needs it. Then when explaining the situation she jumped to an idea of why she could have this sudden pain, without thinking about if it even makes sense that you are all the sudden allergic to plants that have been in your home for a while. The doctor however does come to the conclusion that something is odd about getting a back pain from lifting a watering can. So because Susie is more talkative the doctor decides to do more tests rather than just giving some pain killers.

Chris the ISTP

\quadCleared With his ISTP type, Chris has the dominant function of $T_i$ and then the auxiliary function of $S_e$. We therefore would expect these functions to do most of the work in the dialogue. $T_i$ uses an internal reasoning structure to make judgments about the world and $S_e$ uses the senses to gather information. The conversation can be seen in table tab:chris-conv-doct.

WhoUtterance
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\newlyCleared So this dialogue looks a lot more like that of Sander (INTJ) than that of Susie (ENFP). However the motivation for the responses are quite different than that of Sander. Chris hadn’t figured out yet that he needed pain killers when he arrived, since his auxiliary function is $S_e$, he hadn’t thought that deep about the problem. He just knew he was in much pain, and knew the doctor could help with that.

\quadCleared The difference with the dialogue of Susie is again quite obvious. He didn’t took the initiative because his dominant function isn’t extroverted, and unlike Susie he correctly asserted when the doctor asked about it that the object he lifted may have been to heavy.

\quadCleared The conclusion is again different. Because one of the main functions of Chris is $S_e$ he wants to deal with the pain now. Therefore he asks the doctor explicitly for pain killers, without considering that only the tests could actually solve the problem permanently. However the doctor comes to a middle ground and besides ordering the test also prescribes painkillers.

Influence of personality

\quadCleared So we had 3 different doctor appointments all with the same problem but with different personalities being at play. The end result was three different outcomes for each patient. Sander probably will be back next week with the same complaints at the doctor. However this time his situation may have worsened. Susie will get her problem eventually diagnosed like Chris, however Susie won’t have access to painkillers meanwhile. Which may be uncomfortable to her.

\quadCleared From this case study we can conclude that training doctors to deal with different personalities is in fact very desirable because it can allow patients to be treated sooner and more effective. Sander could have had his problem diagnosed a week earlier and Susie could have had access to pain killers for example.

Making a scenario

\quadCleared Making a realistic dialogue can be difficult. Predicting most utterances one actor can make in a particular niche and adding answers to those is even more difficult. This is what AIML asks of its authors. What our modeling system in YAML asks goes a step further, to predict most utterances all actors can make in a particular niche. We will discuss in this section how we modeled the dialogue and what methods we used to steer particular personalities over particular paths.

Dialogue to YAML

\quadCleared The first task is just getting the utterances and the connections (without steering) into our knowledge base (the YAML files). In this section we will discuss how we modeled a part of the scenario discussed in section Personality influence case study. In that section several dialogues are presented with different personalities dealing with the same social practice, visiting the doctor.

\doubleCleared Our strategy for modeling these is selecting a particular dialogue and then deciding per utterance whether they: Require a unique symbol, can be merged in an existing one, or already have one and therefore can be ignored. For example we merge the greetings according to listing code:yaml:model:greeting.

literals:
  - Hello
  - Hi

\quadCleared While putting utterances into symbols, we can start thinking about how to group them in scenes. Scenes are available to allow pattern matching to be more general by disabling most patterns at a particular point in the conversation (see section Scenes). It’s up to the author to decide what is most handy for using this feature. One may even not use this at all and leave everything in the introduction. What we chose to use was the social practice activities in section social practice as guide for determining what to group in which scenes.

\quadCleared The final step is modeling the connections. We just look at the dialogue and link up the utterances as can be seen in listing code:yaml:model:initial-connections. Since we stick to the social practice for organizing the scenes we put the symbol ask_reason_here in the information_gathering scene (or data gathering in section social practice).

from:
 - greeting
to:
 - symbol: greeting
 - symbol: status
 - symbol: ask_reason_here
   scene: information_gathering

\quadCleared Although these connections are valid for conversation, the bot has no way to know which personality should choose what path. We have two major ways of steering certain personality kinds over certain paths. Namely, perlocutionary values and goals (see section Mapping to process). However to use these we first need to setup the initial believes of the bot. Which will be discussed next.

Believes

\quadCleared An example believes.yml can be seen in listing code:yaml:sc-believes. This file describes several constants in the chatbot, that cannot, or should not be derived. This file in cooperation with the symbols and connection will be used to create an initial believe base.

\quadCleared We need to setup the goals and values, which are the primary steering information sources. The higher a goal is in the goals list the more important it is, with this representation a goal can never be equal in importance. Goals are about informatives being uttered (see section Low level diagram and section Thinking), in our example the bot wants the doctor to utter the symbol have_painkiller most, then after that he wants to tell the doctor he has a back pain. Goals are the most powerful method of steering the thinking functions.

\quadCleared We can also see the utility definition of values, higher is more attractive. Values, unlike goals can have an equal utility. Moreover unlike goals their utility can be added upon each other, this does not happen for goals, which brings us to the next difference. Whereas goals are encoded at believes level, values can be encoded in connections themselves (see section Low level diagram and section Feeling). Also note that this is a dictionary definition, meaning it’s up to the scenario implementer to decide which value names he wants to use. Finally whereas goals were about steering thinking functions, values are about steering the feeling functions.

\quadCleared Then we need to determine the available actors and which actor is the bot himself. This is required to determine which connections can be used, a connection that does not defines restrictions gets expended into the actor list. There was an idea of trying to derive the available actors from connection definitions, however this wouldn’t work in case no actors were ever defined (relying on the expansion mechanism for every connection).

\quadCleared Finally we need to determine the personality this chatbot will use. This is just a sequence of the Jungian function names. There are no restrictions on this, except for your machine resources. You could make a personality of 500 levels deep, but that probably won’t run very well.

goals:
  - actor: doctor
    scene: diagnoses
    symbol: have_painkillers
  - actor: patient
    scene: information_gathering
    symbol: back_pain
values:
  enthusiasm: 8
  polite: 5

self: patient
actors:
  - patient
  - doctor

# ENFP
personality: [Ne, Fi, Te, Si]

\doubleCleared Loading the believes inside a YAML file presents a design conflict: Should believes be loaded from YAML or inside the Drools? There is a constant pull between these two possibilities. Drools is much more flexible, because it is Turing complete cite:weppenaar2011solving, however YAML can be less verbose as just a data format. The issue is that we now indicate that this structure is a standard part of the bot, but it’s only part of the personality component. On the other hand one needs to have a method of deciding which connections ought to be used anyway, if you always want to use the same connections for a pattern you may as well have chosen to use the Alice bot. Doing it this way was also a method of providing a scenario descriptor file, drools however may have been better suited for that. This decision probably needs to be reconsidered once a multilogue architecture will be implemented (see section Multilogue architecture).

Steering the bot

<<steering bot>> \doubleCleared As discussed before the primary sources of steering the bot are perlocutionary values and goals. However these are not our only tools, if we want to make distinctions between introversion and extroversion we need to look closely at the behavior of the functions in question. For example $T_e$ has as default behavior, meaning no goals present, to prefer connections that transition to another scene, whereas $T_i$ prefers connections that lead to more options (see section Thinking).

\doubleCleared In listing code:yaml:model:connext we can see the extended version of listing code:yaml:model:initial-connections, with a glance, we can see how the functions maybe influenced by this. For example we expect personalities with a dominant feeling functions to go for the `status’ option, because it gives so much utility. From the status option there are only options that can be uttered by the doctor, this is done simply because it would be strange to continue talking after asking “How are you?”.

\doubleCleared If the status symbol is liked more by feeling function $F_i$, why did in section Testing Susie (with dominant $F_i$) utter a greeting first? The answer is in low level replies (explained in detail in section Operation), of which we can see an example in listing code:drool:lowlevelreply. What this does is execute code upon insertion of a symbol, in this case it just replies with a greeting. So that drool rule will force all personalities to reply a greeting with a greeting. We modelled the connection to add a perlocutionary value to this reply, which means the learning function $F_e$ will prefer uttering polite replies in future choices.

from:
 - greeting
to:
 - symbol: greeting 
   values:
   - Polite
 - symbol: status
   restrictedo: patient
   values:
   - Polite
   - Enthusiasm
 - symbol: ask_reason_here
   scene: information_gathering
   restrictedo: doctor
---
from:
 - status
to:
 - symbol: ask_reason_here
   scene: information_gathering
   restrictedo: doctor
   values:
     - Impatient
 - symbol: good
   restrictedo: doctor
   values:
     - Polite
     - Happy
rule "Low level hello replies with hello first time"
when
	$pre:PreProcessed($symbol:utterance.what, $symbol.name == "introduction/greeting", $actor:utterance.byWhom)
	$believes:Believes($actor != self)
then
	log.info("low level entry");
	delete($pre);

	final Informative infor = new Informative($believes.self, $symbol);
	final Utterance resulting = $believes.findToFromLastUttTo(infor)
		.map(Utterance::createFromConnection)
		.orElse(Utterance.create(infor.who, infor.what, PerlocutionaryValueSet.empty));
	insert(new Reply(resulting.setByWhom(infor.who), QueryDatabase.empty));
end

\doubleCleared If we take listing code:yaml:model:gathering and the believes into consideration, we can see why thinking functions may like the ask_reason_here option: First of all it’s a scene transition, which is $T_e$ enjoys, but more importantly, telling about the back pain is a goal in the believes. So any personality that can think ahead with its irrational functions and order with a thinking function would probably like this option.

from:
 - ask_reason_here
to:
 - symbol: back_pain
   values:
     - Scary
 - symbol: need_medicine
   values:
     - Concerned
to_defaults:
   restrictedo: patient

\doubleCleared There are several other tools for steering available too which were discussed in section Replacing AIML such as before fields and templates. However these can’t be used to steer personality in particular, besides having an influence on the amount of options, and therefore $T_i$. They can also of course be combined with the methods discussed before.

\FloatBarrier

Testing

\quadCleared To verify our implementation’s correctness we use several testing methodologies. First at the lowest level we use the so called unit tests to verify individual Jungian functions work as described in this thesis. We test these individually by creating specific believes and a dialogue tree for input, then we check the output against an expected believe base and dialogue tree.

\quadCleared On the highest level we have the so called validation tests. With these we check if the bot behaves as expected by setting up a scenario, and then executing the bot, after which we run trough the scenario manually.

\quadCleared Traditionally there is also an in-between option called integration tests, which test combined parts of the system, but does so in an automated manner. However we haven’t used those because setting them up initially takes much more effort than simple unit tests. Validation tests are quick to setup because the process isn’t automated.

Validation test

\quadCleared To do validation tests we will try to model the scenario presented as an example in section Personality influence case study. How this is done is discussed in section Making a scenario. After this we test the bot by playing doctor in the scenario. The results were recorded and can be seen in appendix Test Results.

\newlyCleared There were some issues with the scenario itself, however most issues we found were with the functions and their interactions. The first issue real interaction issue which made us reconsider the design was that ENFP didn’t utter multiple responses (which was discovered in appendix Turn taking issue). This was solved as discussed in section Turn taking, where we reinsert the dialogue tree as drools processing, however with the condition that the functions would prefer actor alternation if equal valuation happens (to prevent infinite loops). The second major issue was the $T_i$ function not using its default behavior (discovered in TI random choice second), which lead us to think about the level at which personality functions ought to operate in the dialogue tree in a more structured manner (see section Function ply depth).

\clearpage

In conclusion

\quadCleared In this work we have shown a possible interpretation of Carl Jung’s theory of types in a chatbot. We built on top of the work of an existing chatbot, but decided to replace the core modeling language with an alternative because there was no space to do deliberation in. This effort resulted in a more flexible, less verbose and more precise method of modelling dialogue. It also made Drools the center of the new chatbot, where each step of processing a user message was decided by business rules.

\doubleCleared Once this was done we could implement our interpretation of Jung and set up a test scenario to test the ideas presented in section Mapping to process. From the test results in appendix final test, we can see that the theory works in the implemented chatbot and scenario for the INTJ, ENFP and ISTP personalities. This could in future work help doctors train in dealing with various personalities as discussed in the introduction. We did not prove however that this will work in all instances. A first step towards that would be to model the theories in section Jungian BDI in a formal language discussed in section Logic of BDI. We haven’t had a need to do such an effort yet, and were more concerned with getting a working implementation.

Discussion

\cleared There are some odds and ends that haven’t been addressed. A really major one is the way we expected the function attitude order type to be and how it was. Section Rational and irrational was expecting an alternating order of rational and irrational functions, so $ABAB$. However upon closer inspection of MBTI specific theory it, turned out to be a rotating order, along the lines of $ABBA$. Although this has little effect upon the dominant and auxiliary functions, this may be problematic for the deeper functions. Additional experimentation is required to verify this problem, and potentially start looking for a solution.

\cleared Another issue is that although the bot is functional, the way we implemented the rational functions is rather simplistic. No actual mini-max algorithm is used (or something similar that would work with non zero sum games). We instead just use static evaluation at each level. So not all dialogue tree information is used in the deliberation, addressing this issue could lead to more varied personalities. Alternative implementations could also be developed for the irrational functions, we leave speculation about these as an exercise to the reader.

Future work

\newlyCleared Considering the move to position Drools in the center of chatbot deliberation, and a novel alternate take on modeling chatbot dialogue, there are a legion of possibilities to extend this work. In this section we will present a brief overview of the more obvious extensions, but we expect there will be many niches we haven’t considered.

Social practice support

\newlyCleared We already hinted in section social practice that social practices were a consideration. However during the implementation we haven’t looked deep into this, except for the fact that Drools maybe a good bases to do this. Although it was already in place, we just made it the center of deliberation. This will make modelling norms for example more easy, for example we can consider it to be not normal when someone utters the same symbol over and over. Since utterances are already recorded into believes for some of the Jungian functions, we can define a norm with a Drools query. Then we can react by moving to a particularly designed scene for repeating one self. There is much more that this can do, which is discussed thoroughly in section social practice.

Multilogue implementation

\quadCleared We discussed the architectural changes required for multilogue in section Multilogue architecture. However as discussed in section Practicalities, there are some deeper difficulties with doing this, the biggest one is timing and interruption. Scheduling is hard (although well studied cite:liu1973scheduling). Timing is hard, considering there is little research on for example chatbot initiative, but this paper cite:spierling2006towards considered bot-bot interaction trough AIML. Since AIML was used in that paper we can safely say they weren’t planning on making a multilogue architecture, because AIML can’t do that as discussed in section Actors.

\quadCleared As discussed in section Related multilogue, there already exists a system that can do this, but it’s drastically different from this architecture. It may be worth more study if one were to take an endeavor to a multilogue based system.

Better use of linguistic theory

\quadCleared Currently linguistic theory is only used on a very basic level, in case of perlocutionary values for example. If symbols and templates were marked with slot grammar cite:mccord1990slot, a more precise use of templates could happen. So connections that go to a symbol that require a noun, would no longer be able to use symbols that matched a verb.

\doubleCleared With help of the work of convolution kernels for semantic parsing cite:moschitti2004study, a simple knowledge base could be constructed as an inspiration for bot about what to fill into the template system. So that bot to bot conversations could also use the symbols with templates. Care must be taken in this case that the connections are still aligned properly, and the insertion of a template does not alter the meaning of a symbol completely. Although currently this is also a potential problem.

More advanced learning

\doubleCleared The idea of dynamically extending the symbol graph, and creating new symbols themselves is an interesting one. For example a new symbol is created every time the bot doesn’t know something, then the bot asks about it and if the user replies with something which is known, connect them. Currently there is limited support for learning in the $S_i$ function. but this is based on knowing existing symbols, the extension would add symbols dynamically. This could be done by more advanced language parsing techniques in combination with an existing knowledge base such as OWL cite:world2012owl.

Matching

<<Replace regex>> \doubleCleared It should be noted that regular expressions is just one of the possible ways of determining what symbol the user uttered. The bot can be easily modified to use alternate matching mechanisms such as trough a recurrent neural network for example cite:vinyals2015neural. What needs to be done is just replace the existing pattern matching drool rule with an alternative and modify the recurrent neural network to select symbols. With probability theory matching could also be made such as done in cite:jin2009opinionminer, this would require slight modification of the ideas proposed in that paper. But the core problem is the same: Figuring out what was said, based upon a set of possibilities. We have symbols in a scene whereas they had a tag set. Finally there could be chosen to improve the existing regular expression approach, for example by executing it in parallel, or even upon the GPU cite:zu2012gpu.

\doubleCleared The question of what to do when multiple symbols are matched is a difficult one. In the initial approach we simply selected the first symbol, however currently they are all selected, and we hope the scenario is designed in a way to deal with that. What should be looked into is if there are ways to combine symbols, or perhaps even select one or several based upon personality. Another approach would be to try and use information theory to select the most precise symbol. However this precision could also be encoded or derived somehow (for example, more words means more information).

\quadCleared Note that at the matching phase personality could play a role, for example preferring to match on different symbols, or if multiple are matched, having a preference for certain kinds of symbols. Sensing types may for example prefer raw data based symbols, whereas intuition types would prefer possibilities and ideas.

Emotions

\doubleCleared In section Fatima Architecture the Fatima architecture is discussed that uses decay rates for emotions. Analyzing this could be a good start for re-adding emotions. They used to be a part of the system, however they were based upon type insertions in the AIML files, and couldn’t influence dialogue beyond changing scenes. Now the dialogue is much more dynamic because it’s completely loaded into memory. However to re-add this, a theory has to be devised of combing OCC with Jung’s functions.

\doubleCleared If we use perlocutionary values as prime source for emotion tracking, then the model can be extended with information on what expected effect the a perlocutionary value has on the bot. Once an utterance is made, the emotional effects are then applied and decay rates are used to slowly return to the norm. With this new model, the bot could predict which connections could change his emotion to a more desirable state. Personality could play a role in the way it would make these predictions. In that way we only would need to encode the expected emotional change per perlocutionary value, and which emotions are desirable to be in. Personality could also play a role in the desire to be in a particular state, for example a thinking dominated personality would rather be calm, whereas an intuitive personality would rather be excited.

Graphical scenario editor

\quadCleared A final possible extension would be to create a graphical scenario editor. Doing this always costs more time than expected and probably should be avoided until above mentioned systems are in place.

\clearpage

Acknowledgements

\tripleCleared There it is, my drop of contribution into the ocean of science. I did this work of course not on my own. Many thanks to my teacher Dr. F. Dignum, for helping me ask the right questions, keeping me focused, and be critical in general about the thesis. Also thanks to Dr. M. Gentile for helping with implementation matters. Finally I want to tank my parents for providing me with housing and a (mostly) calm working environment.

\clearpage \appendix

References

<<bibliography link>>

bibliographystyle:unsrt bibliography:refs.bib

\newpage

List of figures

\listoffigures \clearpage

List of tables

\clearpage

Symbol overview

<<Symbol overview>>

SymbolConstraintsDescription
$f_a$Function attitudes
$\mathcal{B}$Set of all possible believes
$t$time
$B$$B \subseteq \mathcal{B}$Believe $B$
$Π$Set of all possible sense information[fn:not-used:Not used in implementation]
$π$$π \subseteq Π$Perception information $π$[fn:not-used]
$\mathcal{D}$Set of all possible actions[fn:not-used]
$Δ$$Δ \subseteq \mathcal{D}$Set of actions $Δ$ executed[fn:not-used]
$σ$A string
$\mathcal{S}$All encoded symbols
$s$$s ∈ \mathcal{S}, s=(\{σ\},σ)$A symbol $s$
$g$$σ \overset{g}{→} s$Mapping function from $σ$ to $s$
$g’$$s \overset{g’}{→} σ$Mapping function from $s$ to $σ$
$\mathcal{P}$Set of all encoded perlocutionary speech acts
$P$$P \subseteq \mathcal{P}$Set of perlocutionary speech acts
$p$$p ∈ \mathcal{P}$A perlocutionary speech act value
$Λ$Set of all active actors
$a$$a ∈ Λ$an actor
$u$$u=(P,a,s,t)$Utterance made by $a$
$D$$D=(u,[D])$Dialogue tree
$G$A set of connections
$c$$\begin{matrix} c=(P,A,s_1,s_2), c ∈ G \ s_1, s_2 ∈ \mathcal{S} ∧ s_1 ≠ s_2 \end{matrix}$Connection, from one symbol to another
$i$An integer
$h$$p \overset{h}{→} i$Mapping function from $p$ to $i$
$Φ$Set of goals in an agents believe base
$φ$$φ ∈ Φ, φ = (a,s)$A single goal, consisting of actor and symbol

\newpage

\clearpage

Source

<<gaia>> \newlyCleared A free variant[fn::LGPL-2.1 license for the chatbot core and MIT license for reference implementation] of the software is available at https://jappieklooster.nl/chatbot. Note that this source is not the same as the salve game therefore the build instructions in appendix building don’t work for this source. We published the parts which we had copyright over and rewrote some parts we didn’t have copyright over such as the server and client. In the process we also made building a lot easier.

\newlyCleared Building happens with Gradle, which provides a script[fn::You do require a Java SDK to execute this script, for example: http://openjdk.java.net/install/index.html] to install all dependencies (including Gradle):

./graldew run

\clearpage

Building salve

<<building>> \tripleCleared To build the salve game two hurdles need to be overcome, because the server uses a starkly different tool chain than the client. In this appendix we will record how the application can be build. It may seem trivial but the Java EE world is incredibly complex. We assume a UNIX-like operating system with a package manager.

Note that these instructions are not for the source described in appendix gaia

Client

\doubleCleared The client is relatively easy too setup since it’s build with a monolithic environment. You need to have the unity editor. The only issues with the client were an incomplete merge and a dangling import that produced build errors. Also note that there exists a Linux editor, it’s just not officially supported (yet) but the latest version can be found here: https://forum.unity3d.com/threads/unity-on-linux-release-notes-and-known-issues.350256/ Scroll all the way down for the latest release.

\tripleCleared Note that the unity client currently doesn’t support multiple replies from an agent, because the reply is just inserted in a label, rather than showing a chat history.

Server

\tripleCleared The server runs on Java, therefore the first step is to install Java. In our case java 8 was used. If your system uses portage you can use the following command:

# emerge dev-java/icedtea:8

Maven

\tripleCleared Then maven needs to be installed since Gradle didn’t work:

# emerge dev-java/maven-bin

\doubleCleared Maven is the package manager for java software, it downloads and installs dependencies (and dependency dependencies) automatically based on XML configuration. Do note that to use maven you need to setup a \url{\string~/.m2/settings.xml} file. I based mine on this: https://maven.apache.org/settings.html, with help of: https://maven.apache.org/ref/3.3.9/maven-settings/settings.html The active profile should have the name local so that the local profile is used in the maven project (in this case local). Otherwise the Wildfly plugin won’t deploy the application. To test if maven works go to the \url{communicate2/communicate/communicate_server} folder and execute:

$ mvn compile

\tripleCleared If no errors occur it means the settings are configure right. However we are not done yet since the resulting binary is not executable. It is something called a servlet which is an API for server like applications. To use this binary, we need an application server. Our maven repository and code base has been configured towards Wildfly, so we will use that.

Gradle attempt

<<Gradle attempt>> \tripleCleared it was attempted to replace maven with Gradle, since it’s a lot less verbose than maven and easier to setup however doesn’t have the picketlink extension which Wildfly requires. Therefore Gradle was abandoned and the maven tool was used instead.

Get Wildfly

\tripleCleared Download Wildfly from here: http://wildfly.org/downloads/, choose the full web distribution (if you choose the servlet one you’ll run into trouble since it doesn’t have the datasource subsystem, it took about two days to figure that out). Extract this download somewhere which we will call hence forth $WILDFLY.

Setup datasource

\tripleCleared Now it’s time to configure the persistent datasource. The code base can handle sessions, but to deal with user registration and logins and such we need a database. There are two methods, MariaDB and the in ram storage. MariaDB is what the online application uses and it’s probably better to stick to that for active development, but if you just want to have a quick look at the server you should use look at section inmemorydb.

MariaDB setup

<<Mariadb setup>> \tripleCleared So first install MariaDB (or MySQL, they are the same, except MariaDB has better defaults):

# emerge dev-db/mariadb

\tripleCleared Then we need to setup the user and database:

$ mysql -u root
> create database salve;
> GRANT ALL PRIVILEGES ON salve.* To 'salve'@'localhost'
IDENTIFIED BY 'salve';

MariaDB driver

\tripleCleared Now we need to make the application server aware of the database. To do this we first need to install a driver from here: http://central.maven.org/maven2/mysql/mysql-connector-java/5.1.33/mysql-connector-java-5.1.33.jar then copy this jar into \url{$WILDFLY/modules/system/layers/base/com/mysql/driver/main} you probably need to make every folder after base. Also create another file called \url{module.xml} with the following content:

<module xmlns="urn:jboss:module:1.3" name="com.mysql.driver">
 <resources>
  <resource-root path="mysql-connector-java-5.1.33.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.transaction.api"/>
 </dependencies>
</module>

Wildfly datasource

\tripleCleared Now the driver is installed we need to configure it as a datasource. To do this we move to \url{$WILDFLY/bin}. Then execute the following commands:

$ chmod +x add-user.sh jboss-cli.sh standalone.sh
$ ./standalone.sh &
$ ./jboss-cli.sh --connect controller=localhost
--command="/subsystem=datasources/jdbc-driver=mysql:add(driver-name="\
"mysql,driver-module-name=com.mysql.driver,driver-class-name="\
"com.mysql.jdbc.Driver)"
$ ./add-user.sh
$ xdg-open localhost:9990

\tripleCleared That last command should open the browser. Click then Configuration → subsystems → datasource → non xa → add → MySQL → next. The name should be GameDS and the JNDI name should be java:/GameDS, now click: next → detect driver → MySQL. The URL should be \url{jdbc:mysql://localhost:3306/salve}, the username and pass should both be salve, now click next → finish.

Deploying

\tripleCleared first go to the \url{communicate2/communicate/communicate_server} folder. Then to deploy the application the following command is used:

$ mvn wildfly:deploy

\tripleCleared If your build gets stuck because it tries to find communicate jars from the internet it can help to go to the project root folder and execute:

$ mvn compile

Alternative: in memory db

\doubleCleared <<inmemorydb>> Note that I didn’t test this but it should work. You can either choose to use maria db or try and point the application to the in ram storage of Wildfly. To do this go to: \url{communicate2/communicate/communicate_server/src/main/resources/META-INF} and then replace everything with:

  <?xml version="1.0" encoding="UTF-8"?>
  <persistence version="2.1"
  xmlns="http://xmlns.jcp.org/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"
  xsi:schemalocation=
  "http://xmlns.jcp.org/xml/ns/persistence 
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
  >
      <persistence-unit name="salve_persistence_unit"
          transaction-type="JTA">
          <jta-data-source>java:jboss/myDs</jta-data-source>
          <properties>
              <property name="hibernate.dialect"
                        value="org.hibernate.dialect.H2Dialect" />
              <property name="hibernate.max_fetch_depth" value="3" />
              <property name="hibernate.hbm2ddl.auto" value="update" />
              <property name="hibernate.show_sql" value="true" />
          </properties>
      </persistence-unit>
  </persistence>

Ubuntu issues

\doubleCleared At some point my laptop crashed and I had to fall back to an Ubuntu based distribution. Installing MySQL came with the gotcha, the default root on MySQL is only accessible from:

sudo mysql -u root

I thought I could do this as the normal user but it appears this not the case. Also an online forum said that you had to run

sudo mysql_install_db

However I think apt handles that for you.

utf8 problem

\tripleCleared I got an error:

com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:
  Specified key was too long; max key length is 767 bytes

This is because it uses an utf8 encoding (see this website: http://stackoverflow.com/questions/10748155/specified-key-was-too-long-max-key-length-is-767-bytes). To solve this change the tables to use a smaller utf8 instead. In `/etc/mysql/mariadb.conf.d/50-server.cnf` change the variables to

character-set-server  = latin1                                                            
collation-server      = latin1_swedish_ci

\tripleCleared We also need to modify `/etc/mysql/mariadb.conf.d/50-client.cnf` with:

default-character-set = latin1

\tripleCleared After which we do a restart of the mysqld:

sudo systemctl restart mysql

\tripleCleared Note: make sure to stop your running Wildfly instance, otherwise Wildfly will keep it alive

\tripleCleared Now drop the entire salve database as root, the tables were created with the wrong char-set so we need to just remove them all.

mysql -u root -ppassword -e "DROP DATABASE salve;:

\tripleCleared Now recreate the database as was done in section Mariadb setup (alternatively logging in as root and pressing arrow up a couple of times should get you the right commands).

Notes

\tripleCleared If you’re located in the communicate_server folder, The rebuild everything command is:

rm -R ~/.m2/repository/cnruithof; (cd ../ && mvn clean && mvn install) && mvn wildfly:deploy

There is also a shell script rebuild.sh. This will re-install the entire project thereby also rebuilding all dependencies. mvn clean in there for good measure.

\tripleCleared There is a python client script for quick debugging, therefore it’s unnecessary to keep unity running (or use at all).

\newpage

Test Results

<<Test Results>> \tripleCleared All these test follow the scenario which is presented as case study in section section Personality influence case study. Each time all tests are executed to prevent regressions, even if they did manage to pass a test cycle before. Every test we indicate the commit hash on which it was performed upon for reproducibility reasons.

Initial test

Commit65e704a0f9ec6f5d7052e0de285a79baf420db7d
Date2017-03-28

\tripleCleared We believe most of the higher level reasoning is done at this point. Therefore we attempted this acceptance test to see how well the system would hold up.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello1
DoctorHow can I help you?2
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared

  1. Actually said “How are you?”, This is unexpected, however since replying with hello is useless to INTJ (it’ll just loop back), such a reply may actually be better for progress high level process. However, this doesn’t mean this is right, the intention was to make the hello reply be done on a lower level (first item said and understanding matches hello short-circuits into replying hello)
  2. We use the other scripted response (perhaps it thinks it’s ENFP), this didn’t match however, turns out this symbol didn’t have any regular expressions, after adding the regular expressions it still didn’t match, further investigation is required into the regular expressions why they don’t match, I’m suspecting it’s either a construction problem (not all are added), Or some standard java regex problem.

ENFP

<<Turn taking issue>>

WhoUtteranceIssues
DoctorHi
SusieHello1
SusieHow are you today doctor?1
DoctorI’m good, how can I help you?2
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/3
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.4
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared

  1. Skipped saying hello (again we miss the short circuit rule, same as INTJ)
  2. Didn’t match with I’m good, probably same issue as INTJ.
  3. Only says the first sentence. This is because we don’t keep on popping sentences from the dialogue tree if the patient actor still is preferred.
  4. We skipped the intermediate sentences (because they didn’t pop), What we would expect is to get some confusion back after doing this. This didn’t happen so rules to give confusion when skipping parts of the graph should be implemented.

ISTP

<<TI random choice first>>

WhoUtteranceIssues
DoctorHi
ChrisHello1
DoctorHow can I help?
ChrisI have back pain doctor.2
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/3
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\tripleCleared

  1. Again no hello
  2. Replied with, I’m afraid I need some medicine, I think this is because $T_i$ is the first function, and I think the two pass effect isn’t implemented correctly yet. It just goes deeper now rather than finding the right level to modify. Since telling about back pain is a goal and we have a unit test that ti prefers goals it’s almost surely this broken two pass behavior.
  3. It says when lifting a heavy object, but I’m pretty sure it just always picks the first option because two pass logic is broken. So I’ll end this test prematurely.

Second test

Commit1de05450c187c51df780a975cc4f0cec7c69dba1
Date2017-04-05

\tripleCleared After solving the issues from the initial test, we redid them.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?1
DoctorI’m good, how can I help you?2
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.3
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared

  1. Wasn’t uttered, probably because we handle hello as a low level reply. Perhaps we should let replies also be passed to themselves so higher level functions have a chance to interact? (note that alteration is the default, so unless a goal is directly below it nothing will be said)
  2. We just said ‘how can I help you’ instead.
  3. Goes into “Perhaps I put to much water in the watering can”. Probably because ENFP is an $F_i$ rather than $F_e$, $F_i$ is a learning function [fn:: note I got this wrong here in my initial analyses, $F_e$ is the learning function]. We should analyze what has been learned at this point. It appears also that in either case no values are attached. After this point the bot follows the ISTP script. This is wrong, $F_e$ is the learning function, $F_i$ uses perlocutionary values. So this was easily fixed by modifying the perlocutionary value utility.

ISTP

<<TI random choice second>>

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/1
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\tripleCleared

  1. Says ‘when lifting a heavy object’. This derails the entire script so the test was stopped. The reason for this became apparent after a full tree dump after each function. First time the $T_i$ function has nothing to sort, so it does nothing. $S_e$ generates all available options in the order they came, $N_i$ just goes down whatever $S_e$ preferred. $F_e$ sorts everything twice, but most have no perlocutionary value. Then once we come back to $T_i$, the most obvious choice is of course the first option provided by $S_e$, since it was expended by $N_i$, twice.

\tripleCleared This is obviously not what we want, since $S_e$ is deciding which action is taken here. $S_e$ could try and get a sane ordering function. However it only has next available and trying to use previous would lead to a stack overflow. $T_i$ probably should get a better ordering mechanism. For example rather than using the DialogueTree for direct options we just list all available options. We ended up doing this but note that this breaks the design idea of the architecture.

\tripleCleared To fix this properly we need to reconsider the design at a deeper level, for example give ti the opportunity somehow in with direction $N_e$ will go down. A potential better way of solving this would to allow irrational to either produce on the level of previous irrational, or if the produced action already exists, go one lower. But since we’re starting to run into time constraints we just leave it at this `solution’.

Third test

Commit893f54f6942a65e3c22126949091d096c3691445
Date2017-04-10

\tripleCleared After solving the issues from the second test we did another run of all tests. Even though this time we tested quite closely against the issues from the previous test, going trough the entire battery is necessary to prevent regressions.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared Conversation went according to script.

ISTP

WhoUtteranceIssues
DoctorHi
ChrisHello1
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?2
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\doubleCleared

  1. Said hello twice?! This was caused by the reinserting part of the shortcut, it used any actor rather than self. Fixing this caused a regression in ENFP which wouldn’t ask about the doctor’s day anymore. This was solved by adding an extra value to that connection (making it more appealing for $F_i$).
  2. Said “of course” rather than give me some pain killers After inspection of the scenario it appears that there is no reason to say “can’t you give me painkillers” because there weren’t any connection leading out of it. I also made give painkillers a low priority goal, to force ISTP in that direction.

Fourth test

Commit8ea894d0da28addd8067c341e842ca2d91296586
Date2017-04-10

\tripleCleared It’s the same day and we try another round to try and pass this. Although we modified ISTP slightly, because it had to parse a large amount and produce a single reply for no obvious reason. Unlike ENFP which for example is expected to produce multiple replies because it’s talkative.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared Conversation went according to script.

ISTP

<<Changed istp test slightly>>

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\tripleCleared Conversation went according to script. Note however that we split up the utterances of the doctor compared to the scenario. This is because there were to many different symbols in the input (scan and give painkillers), this made the bot reply to both of them.

Fifth test

Commitae74151591d0c5a20566d8d74283d4c73e9450d2
Date2017-04-30

\tripleCleared This test was done after completing the major features that were still missing in comparison with AIML. We wanted to make sure no regressions had occurred meanwhile.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared Conversation went according to script

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared Conversation went according to script

ISTP

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.1
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?1
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\tripleCleared

  1. It didn’t match these sentences, apparently because of the new scene system. There was no connection for this transition.

Sixth test

Commite15409ffc37b837a47a9ceb3c183d67f18c3eb17
Date2017-04-30

\tripleCleared Because of the ISTP issues in last test we wanted to try and pass this one.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\tripleCleared Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\tripleCleared Conversation went according to script.

ISTP

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\tripleCleared Conversation went according to script.

\newpage

Seventh test

Commitbda8dcfb77e7f144ae04eb930611ea74f311a8e7
Date2017-06-09

\toReview Before handing in the project I wanted to do a final acceptance test.

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\toReview Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\toReview Conversation went according to script.

ISTP

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\toReview Conversation went according to script.

\newpage

Eighth test

<<final test>>

Commitfca7c62eb90e8f2021f92f9f74b9468306c1aebb
Date2017-06-09

\toReview Before handing in the project for rc-2, I wanted to do another final final acceptance test, this time using the public repository and commit hash (see appendix gaia).

INTJ

WhoScripted UtteranceIssues
DoctorHi
SanderHello
DoctorHow can I help you?
SanderI have a back pain.
DoctorWhen did this first occur?
SanderWhen I lifted a heavy object.
DoctorOh, yes then you need some pain killers for this.
SanderThank you doctor

\toReview Conversation went according to script.

ENFP

WhoUtteranceIssues
DoctorHi
SusieHello
SusieHow are you today doctor?
DoctorI’m good, how can I help you?
SusieI’m afraid I need some medicine
DoctorMedicine? Why do you need that?
Susie/Well, I was watering the plants and all the sudden,/
SusieI got this pain in my back.
SusieDo you think I’m allergic to plants?
DoctorHa ha, no, I think we need to make a scan of your back.
DoctorBecause a watering can is a little to light to get back-pain from.
SusieOf course doctor.
DoctorCan you go to the hospital next Friday at 13:00?
SusieYes, I will go then.

\toReview Conversation went according to script.

ISTP

WhoUtteranceIssues
DoctorHi
ChrisHello
DoctorHow can I help?
ChrisI have back pain doctor.
DoctorWhen did this first occur?
Chris/Well I was watering the plants,/
ChrisPerhaps I put to much water in the watering can
DoctorYes, that could be the case.
DoctorHowever I would like to make a scan of your back just to be sure.
ChrisCan’t you just give some pain killers to help me?
DoctorYes but that will only work temporary.
DoctorSo let’s plan a scan at the hospital next Friday at 13:00?
ChrisYes, I will go then.
DoctorI can give you some pain killers meanwhile.
ChrisOkay, thanks doctor

\toReview Conversation went according to script.

\newpage