1. TrindiKit A toolkit for building and experimenting with dialogue move engines and systems, based on the information state approach

2. The information state approach – key concepts Information states represent information available to dialogue participants, at any given stage of the dialogue Dialogue moves trigger information state updates, formalised as information state update rules Update rules consist of conditions and operations on the information state

3. The information state is an abstract data structures (record, DRS, set, stack etc.) Modules (dialogue move engine, input, interpretation, generation, output etc.) access the information state DME (Dialogue Move Engine): module or group of modules responsible for integrating and generating dialogue moves Resources (device interface, lexicons, domain knowledge etc.) are hooked up to the information state TrindiKit architecture

4. input inter- pret Information State device interface control updateselect gene- rate output lexicon domain knowledge DME device manager

5. A library of datatype definitions (records, DRSs, sets, stacks etc.) A language for writing information state update rules Methods and tools for visualising the information state debugging facilities TrindiKit components

6. A language for defining update algorithms used by TrindiKit modules to coordinate update rule application A language for defining basic control structure, to coordinate modules A library of basic ready-made modules for input/output, interpretation, generation etc.; A library of ready-made resource interfaces, e.g. to hook up databases, domain knowledge etc. TrindiKit components (cont’d)

7. TRINDIKIT dialogue theory (IS, rules, moves etc) domain knowledge (resources) domain-specific system Building a system domain-independent DME software engineering (basic types, control flow)

8. Starting from a theory of dialogue management, build or select from existing components: Type of information state (DRS, record, set of propositions, frame,...) A set of dialogue moves Information state update rules, including rules for integrating and selecting moves DME Module algorithm(s) and basic control algorithm ****** Building a domain-independent DME

9. Domain-specific system Build or select from existing components: Resources, e.g. –domain (device/database) interface –dialog-related domain knowledge, e.g. plan libraries etc. –grammars, lexicons Modules, e.g. –device action manager –input –interpretation –generation –output

10. Explicit information state datastructure makes systems more transparent Update rules provide an intuitive way of formalising theories in a way which can be used by a system Domain knowledge encoded in resources; the rest of the system is domain independent –plug-and-play –to adapt system to new domain, build resources (provided the system handles the kind of dialogue needed for the device, e.g. information-seeking, instructional, negotiative etc.) TrindiKit Features

11. Features, cont’d Allows both serial and asynchronous systems Interfaces to OAA (only available for UNIX) Generic WWW interface Runs on UNIX, Windows, Linux etc. Needs SICStus Prolog Version 2.0 is available, next version expected early 2001 (SIRIDUS) www.ling.gu.se/projects/trindi/trindikit

12. Asynchronous TrindiKit Uses AE (Agent Environment), basically a stripped-down OAA Can also run on top of to OAA (but this makes it a factor of 10 slower) Can run with AE but still interface to OAA, –by making TrindiKit modules/resources be OAA agents as well OR –by making the whole TrindiKit-based system into an OAA agent

13. Extensions Modules for speech input and output, for using off-the-shelf products (we currently have ViaVoice speech out on Linux) Extend libraries of ready-made modules and resources *** *** GUI for increased usability and overview, including tools for building systems Improved domain-independent facilities for handling dialogue plans Information states including Nuance semantics (?)

14. GoDiS and IMDiS – information state based on Questions Under Discussion MIDAS – DRS information state, first-order reasoning EDIS – information state based on PTT Autoroute – information state based on Conversational Game Theory Systems developed using TrindiKit

15. An experimental dialogue system built using the TrindiKit GoDiS

16. Information-seeking dialogue Information state based Ginzburg’s notion of Questions Under Discussion (QUD) Dialogue plans to drive dialogue Simpler than general reasoning and planning More versatile than frame-filling and finite automata GoDiS features

17. PRIVATE =PLAN = AGENDA = { findout(?return) } SHARED = findout(? x.month(x)) findout(? x.class(x)) respond(? x.price(x)) COM = dest(paris) transport(plane) task(get_price_info) QUD = LM = { ask(sys, x.origin(x)) } BEL = { } TMP = (same structure as SHARED) Sample GoDiS information state

18. integrateAnswer Before an answer can be integrated by the system, it must be matched to a question on QUD pre: eff: in( SHARED.LM, answer(usr, A)) fst( SHARED.QUD, Q) relevant_answer(Q, A) pop( SHARED.QUD ) reduce(Q, A, P) add( SHARED.COM, P) Sample update rule

19. Typical human-computer dialog S: Hello, how can I help you? U: I want price information please S: Where do you want to go? U: Paris S: How do you want to travel? U: A flight please S: When do you want to travel U: April S: what class did you have in mind? … S: The price is $123

20. Dialogue plans for information- seeking dialogue Find out how user wants to travel Find out where user wants to go to Find out where user wants to travel from Find out when user wants to travel … Lookup database Tell user the price

21. Typical human-human dialogue S(alesman), C(ustomer) S: hi C: flights to paris S: when do you want to travel? C: april, as cheap as possible...

22. Question accommodation If questions are part of the information state, they too can be accommodated If the latest move was an answer, and there is an action in the plan to ask a matching question, put that question on QUD Requires that the number of possible matching questions is not too large (or can be narrowed down by asking clarification question)

23. Update rule for question accommodation QuAcc pre: eff: in( SHARED.LM, answer(usr, A)) in( PRIVATE.PLAN, findout(Q)) relevant_answer(Q, A) delete( PRIVATE.PLAN, findout(Q)) push( SHARED.QUD, Q)

24. Question and task accommodation in information-seeking dialogue S: hi U: flights to paris system finds plan containing appropriate questions, and loads it into the plan field in the information state system accommodates questions: how does user want to travel + where does user want to go, and integrates the answers “flight” and “to paris” system proceeds to next question on plan S: when do you want to travel?

25. Adapted for travel agency and autoroute domains, as well as acting as interface to handheld computer or mobile phone Lexicons for English and Swedish Question and task accommodation to enable mixed initiative (useful also in command dialogue -> Stina) Simple “optimistic” grounding strategy Focus intonation based on information state contents Also being extended to handle negotiative dialogue (SIRIDUS) GoDiS features (cont’d)