If you want to react on an event, such as user input or sensor notifications, you have multiple options, some of which are used in combination. Essentially, you need to have 3 things:
- An event that is triggered
- An action that is performed
- A connection between the event and the action
Triggering the event:
Events are usually triggered by an input device. For example, a microphone input device can trigger a speech input act, or a GUI device can trigger a button press event. If you are using a device that is not yet covered, you may need to add a new device. For example, if you would like to react when a robot reaches a certain position, you can create a custom device for your robot, and have the robot notify SiAM-dp of the position change via the SiAM-dp i/o interface. (You have to decide whether to extend the i/o model or use the ad-hoc custom i/o message format.) Learn more.
In a situation where you have an existing type of input event, but your dialogue application needs the event in a different (semantic) format, consider writing an input interpreter that transforms an input event from syntactical to semantic form.
Implementing the action:
Actions are usually performed by an output device. For example, a speaker output device can play synthesized speech (TTS), or a GUI device can display a message. Like for input devices, you can create your own device if you do not find an included device that covers your requirements. For example, you could create a robot device that can react to Move actions. Learn more.
In a situation where you have a semantic type of output event, but your device needs the event in a syntactic device specific format, consider writing an output generator that generates a device specific syntactial output event from the semantic one.
Using output devices yields a high reusability of actions, i.e. you can use the external device implementing the action in multiple dialogue applications. However, there is some overhead involved in creating a device, in particular if it’s an external device. A faster alternative to define actions is to write a plug-in. This is simply some Java code integrated into the dialogue application. A method of your plug-in class can be executed as reaction to an event. Learn more.
Connecting event to action:
You normally define the reaction (relations between events and actions) as part of the dialogue model. Using the declarative syntax ensures that the dialogue application remains easy to maintain. With the dialogue being modeled as a state chart, the reaction to an event is a transition between states in SiAM-dp. So you first need to pick the state in which you want to react to the event, and then create a transition to the state where the event leads to (this can be the same state). The transition will be annotated with the event itself (or rather type of event to be matched). The action to be performed is described either in the same transition, as entry conditions of the target state, or exit condition of the source state.
In some rare situations, you may need to filter and react to events purely programmatically, for example when you want to implement your own dialogue management that is not based on state charts. In this case, you can be notified of all incoming events by writing a plugin for a new component that subscribes to a specific set of messages which is filtered by PPatterns. (A wizard that supports the creation of a new component plugin will come soon.)
← I want the dialogue to “do something” on certain events. What options do I have?