Version 2 (modified by masc01, 9 years ago) (diff)


State information defined in the current SEMAINE system

The SEMAINE system needs to maintain various kinds of state information: the context, such aswhich character is currently active, and whether or not there is a user present; the agent's mental state; the agent's interpretation of the user's behavioural and emotional state; and the state of the dialogue.

In a Message-Oriented Middleware (MOM) it is not straightforward to preserve a centrally held state in such a way that several components can access it, because a MOM does not provide a shared memory. One option for implementing distributed access to state information would have been a specialised information repository component; however, this would have required each component to send and receive a message every time that it wants to access a certain information.

The solution implemented in the SEMAINE API is of a different kind. A specialised class State­Receiver is keeping track of state-related messages; it parses incoming messages and saves the information in a local information repository. That means, every component has local access to its own copy of the latest state information. Since the local copies are updated through the same state-related messages, they are updated in synchrony. Looking up a certain piece of information is thus as easy as accessing a local variable.

An important challenge in this kind of setup is to make the encoding-decoding link between the representation of information in XML-based messages, and a unique “short name” by which components can access the information. For example, the dialogue state information that the agent does not have the turn at the moment is encoded as follows:

<semaine:dialog-state xmlns:semaine=””>
	<semaine:agent believesHasTurn=”false”/>

The component, on the other hand, should be able to access this information independently of the representation format, e.g. through a short name such as agentHasTurn.

If the link between message format and short name were hard-coded in the program code, it would not allow users to flexibly reuse the state information mechanism in novel domains and applications, which would be incompatible with the SEMAINE API's ambition to be a reusable framework. Therefore, we have developed and implemented a mechanism that allows developers to represent this relationship in a configuration file, using namespace-aware XPath expressions. XPath is a formalism for navigating through XML documents to access information. In the above example, the information whether or not the agent belives it has the turn can be accessed by going to the element <dialog-state> in the namespace, then to the child element <agent> in the same namespace, and finally by accessing the value of the attribute believesHasTurn. In XPath, this can be encoded as:


where the namespace prefix semaine is bound to the namespace By associating this XPath expression with a short name userHasTurn, it is possible to provide the relation in a configuration file.

XPath in its general form is a very powerful framework which is intended only for accessing information in existing XML documents. It is not originally intended to be used for the generation of documents. However, by using only the subset of navigating to elements and accessing attribute values or textual content, we can reuse the XPath expressions also for the generation of XML documents and thus for encoding the information.

As a result, we have a fully configurable mechanism for encoding and decoding state information. The current content of the configuration file is at trunk/java/config/stateinfo.config. It can be seen that both the relation between short names and XPath expressions and the namespace prefixes can be given in the configuration file, providing full flexibility for future extensions.

The following tables aim to give a complete account of the meaning of state information currently defined.