A variety of different approaches to dialogue processing have been proposed in the past. An approach similar to ours is the one reported in [Papineni et al1999]. Similarly to the goal descriptions presented here and in [Denecke1997], tasks are described by what is called a form. A form is basically a set of slot-filler pairs. Interaction between the user and the system is governed by declarative scripts that contain the specification of the task model, the message prompts and possible error messages. These scripts determine the functionality of the entire application. This approach also displays one of the key features of our approach, namely information-driven dialogue flow. However, the authors do not report on how ambiguity and inconsistency is represented. Moreover, we feel that the type discipline imposed on the representations by the type hierarchy facilitates system design since it not only allows us to detect errors in the specification during system design, but also allows for a graceful degradation should inconsistent representations combine.
Some features of our system bear similarity with features implemented in the Artimis system [Sadek et al.1997]. These include domain-independent speech acts, the joint application of a domain-independent and a domain-dependent model and explicit representation of a persistent goal. However, the systems differ in the way information is processed. The behavior of the Artimis system is specified by a set of basic rational principles, expressed in modal logic. Principles governing communication are domain-independent, while non-communicative principles may be domain-dependent. The action to be undertaken by the dialogue system is determined by an inference process. In contrast, our system relies on less powerful logical foundations (the description logic underlying typed feature structures) and inference processes. Instead of having a theory based on rational principles, our system periodically compares available information with the information necessary to perform one of the possible goals. Consequently, a specification of a task resolves to a specification of a lower bound of information (expressed in a feature structure), together with the associated actions (expressed in a clause). Since these concepts are closer to forms and standard programming languages, a system designer may find these specifications more convenient to use than axioms in modal logic.
Compared to dialogue systems that have explicit representations of states such as finite-state-based systems, we feel that our information-centered approach leads to more flexible dialogues and potentially avoids unnecessary clarification questions. The reason is that for example database requests may be executed at any time in the processing chain and partially instantiated representations may be filled with information stemming from databases instead of having to ask the user to provide complementary information.