Chatbot Module

The Chatbot module is the most important module in the RIVALE which was developed. It supports the chatbot functionalities used to simulate interviews done by a virtual agent. The chatbot module in the first version used by the first prototype only supports single user interviewing. This means that every user can only interview a bot alone and need to share the information after. The reason for this is to simplify the first version because the module does not need a simultaneous state with other students or supervisors and therefore the server side implementation was not necessary. The module has two different chat available which are working both with their own system.

The first type supports an ALICE implementation provided via Internet connected hosted on Pandorabots.com. This is the most convenient way to use ALICE, because there is no need to implement the ALICE system on the server and therefore no extra work for OWL hosts. The connection is made via simple HTTP calls done by the module. The other side is that the chatbots can be hold up to date in real time. Often systems have to be shut down to change content and normally especially extending databases needs a certain level of technique knowledge (an expert). With Pandorabots a supervisor can, without special knowledge, edit the AIML files while the students are working with the system.

The second chat type is managed and gives the user a list of questions to choose from by entering numbers. This type is used to tell a story in an easy way to the students. The questions are set with an extensible markup language (XML) file.

The chatbot system is implemented as capabilities. Every inworld cell can attach a chat. This was done to have the alternative to add the chat to e.g. a computer and simulate in this way a kind of a chat via a computer system. The Figure 40 shows the chatbot properties field. The name is important to set because after chatting the log will be saved and then connected to a user identified by the name of the bot. Here also the choice of Pandorabot or managed chatbot is set. The XML for a managed chat has to be placed in a user folder on the server and can be address with the standard OWL database path pattern e.g. “wlcontent://users/Pirmin/game/tutorial_chat.xml”. The “BotID” is provided by Pandortabots.com and set by publishing a bot on the site. Every object can only have one connected chatbot.

Figure 40: Chatbot properties field

The chatbot system is ALICE using AIML files as knowledge source. The system is provided by Pandorabots. Pandorabots provides free basic AIML knowledge bases with over 60,000 entries (AI Foundation, Inc., 2013a). RIVALE uses two approaches to improve the chatbots brain. The two

developed “characters” Carol and Susan have both separate and not connected sources. At the developing process from Carol an empty base was used and has now more or less only content related knowledge available. Susan on the other side is implemented with the example bot knowledge base from Pandorabots. She got, as said before about 60,000 entries, which are obviously not all related to the topic. The idea is to find out which developing approach is the better. Expected is that Susan might seem to be clever because she can talk about a lot of different topics and not only about the store. On the other side she might often respond unexpected and incorrect because it is impossible to update all 60,000 entries in a way the researchers would like it. More about this will show the evaluation. There are also five chatbots using the guided chat. They are manly telling the story and give some tips and information on tasks.

Figure 41: pandora chat window

Figure 42: manged chat window

A cell which has a chatbot capability has always a “talk” item in the context menu as shown in Figure 45. This can be opened by right clicking on the object representation in the world. The two chat windows are made in the style of the normal OWL chat. The difference, as showed in the Figure 41 and Figure 42, is the extra space with the provided questions in a managed chat window.

Figure 43: simplified client side class diagram from chatbot module

Class Description

The chatbot module has only a few classes in the common and server packages. This classes sharing are for storing the properties information. The main part is done on the client side. The module is like OWL defines a .jar file. The common and the server side classes are done in the normal OWL way with only small changes, thus this explanation will focus on the client side architecture of the chatbot module.

Figure 43 shows the client side class diagram. There are three parts in which the client site can be split. The general part is handling the module functions with the ChatbotComponent class as module entry point, the ChatbotComponentFactory class is responsible for naming the module and initialization the server state object and the ChatbotComponentProperties representing the properties sheet discussed before. Also important is the MyContentRepositoryImporter handling the upload from the chat logs. Every chat log is sent to the server and saved. This has two reasons, first, the user can then later log in from another computer and would still have the same log files in his logbook and second, the files are stored on the server for the supervisors to control the student’s inputs as well as to learn what the chatbot has answered wrong and has to be updated.

The two different chatbots have their own classes. Depending on the properties settings is always one of the chats loaded. The managed chatbot is handled by the ManagedChatManger providing the answers for the client window ManagedChatBox. As explained before, the managed chat has an XML file defining the content for the chat. This is defined by the DocEntry class, loaded with the ManagedChatQuestionsStore and rapped into ManagedChatQuestions. The Pandorabot chat is handled by the PandroaManager class. This class handles the Pandorabot instant and all related actions to communicate with an online Pandorabot.