Overview¶

Blackboard¶

A so-called blackboard is used to manage the input. All inputs, whether from external sensors (gesture devices), voice inputs or processed inputs by an NLU system, land on this blackboard. These entries are stored as so-called tokens. These tokens can then be used to control the dialogue and interact with the user. To prevent the blackboard from overflowing, tokens have 3 life phases: First they are active, after a certain time they are pulled into the archive and after another period of time they are deleted.

Tokens¶

The tokens are the input elements of the blackboard. In principle, tokens are parsed JSON objects. In addition, tokens can be given a type that requires certain properties (e.g. the type PointingGesture would require a property Target). This makes it possible to later formulate very simple rules that can process inputs.

Rules¶

Rules are at the heart of stepDP. They react to tokens in the Blackboard and perform actions. There is a set of predefined rules that allow, for example, the fusion of two tokens into a new token. In addition, you can also build your own rules to construct your own dialogue. For example, a rule can be created that reacts to tokens of the type GreetingIntent and issues a greeting.

Condition¶

Conditions are part of the rules. A condition determines when a rule is to be triggered. Each rule has such a condition. There are simple conditions that simply match the Type. But more complex conditions are also possible, so that, for example, a certain parameter must have a certain value and the like.

Knowledge Base¶

There is also a knowledge base in which persistent knowledge can be stored. A strict distinction is made between types and instances. The types are defined in the so-called semantic tree. The tokens can also derive from these types, so that e.g. conditions involving the type are possible. Once you have specified your types, concrete instances can be saved, changed and recalled later. In addition, tokens are also instances that can be processed in the knowledge base. Thus, a token can refer to a knowledge base instance and vice versa. This allows, for example, if a token of the type PointingGesture comes in and has the target "cube 1" and the "cube 1" exists in the knowledge base, to resolve this object directly.