User Interface Service Software Developerís Guide - Hitech Projects

January 2008
Public
Fallback solutions: a lightweight subscription mechanism may be developed specifically for the
DM
3.3.3.3 Dialogue Manager Internals
The dialogue manager is mainly composed of a blackboard that contains all user inputs and
system outputs. Regarding system outputs, a controller checks every current output requests
on the blackboard and actually realizes them. This give possibility to solve conflicting outputs
on the same terminal, by writing dedicated blackboard knowledge sources that detect and
handle such conflicts.
Regarding user inputs, the fundamental UI services like speech recognition simply publish
these inputs onto the blackboard, while more advanced UI services shall first subscribe to
such events, update/merge them, or even build new interaction events, and publish them back
on the blackboard. Advanced UI services can thus handle conflicting user inputs, or solve
ambiguous inputs.
Other user inputs clients, typically applications, can thus simply call the subscribe method of
the Dialogue Manager and describe the types of user events they are interested in. These
clients actually use the same procedure than any classical context consumer, where the
details of the user events are encompassed within the SPARQL query.
The main advantage of this blackboard architecture is its flexibility, which makes the
development of new advanced UI functionalities easy to realize and to integrate. The
blackboard functionality is not directly implemented by the Dialogue Manager Amigo service.
The actual blackboard is provided by the PEGASUS framework. The Amigo service provides
integration into Amigo and easy-to-use interfaces for other Amigo services.
3.3.3.3.1 PEGASUS
This section provides only a short insight into the architecture of the PEGASUS framework.
The complete overview along with a lot of examples and a developer guide for various
programming languages is available in the document “Pegasus-Manual.pdf”, which is available
at gforge.
The PEGASUS framework introduces an abstract manner of describing a system that consists
of:
• Objects of functionality within data contexts
• Communication of objects through trigger concepts and data structures
In the context of this framework, a PEGASUS object implements the following concepts:
• Data Storage
• Triggers
• Functional parts
In PEGASUS, XML is used for the representation of data. A scope of a piece of data reaches
from a simple XML element to whole XML trees. In every PEGASUS project, one master
application has to hold and maintain the so-called main tree. This tree can be read,
manipulated and even extended by other PEGASUS applications. These applications can use
subscriptions to be notified upon the change of the arbitrary parts of the XML tree. The main
XML tree basically represents the blackboard in PEGASUS. Since various PEGASUS
applications may concurrently access parts of the XML tree, the framework has to make sure,
that all applications, at all time, are working on the same data. For this purpose, PEGASUS
uses distributed XML trees. Access to XML elements is only allowed through PEGASUS’s API,
which handles the steps needed for concurrent and distributed read and write access on XML
elements. This way, application developers can ignore the fact that the XML elements they are
Amigo IST-2004-004182 85/114