TrindiKit

Staffan LarssonGöteborg University

Sweden

What is TrindiKit?

• A toolkit for dialogue systems R&D• Based on the Information State Update

approach• Aims to close the gap between theory

and practice of dialogue systems– today: complex theories, simplistic systems– adapt theories to make use of them in

systems

Theoretical advantages of TrindiKit

• theory-independent– allows implementation and comparison of

competing theories– promotes exploration of middle ground

between simplistic and very complex theories of dialogue

• intuitive formalisation and implementation of dialogue theories– the implementation is close to the theory

Practical advantages of TrindiKit

• promotes reuse and reconfigurability on multiple levels

• general solutions to general phenomena enables rapid prototyping of applications

• allows dealing with more complex dialogue phenomena not handled by current commercial systems

Key ideas

• thinking in terms of IS updates– update rules

• functions IS (+moves) IS (+moves)

• generic domain-independent dialogue management– requires modularity

• use of global information state – all modules can access all information

module1 module…

Total Information State (TIS)•Information state proper (IS)•Module Interface Variables•Resource Interface Variables

resource1

control

modulei modulej module… modulen

resource… resourcem

DME

TrindiKit

basicdialogue theory

domain & languageresources

basic system

application

information state approach

genre-specific theoryadditions

genre-specific system

• explicit information state datastructure – makes systems more transparent – enable e.g. context sensitive interpretation,

distributed decision making, asynchronous interaction

• update rules – provide an intuitive way of formalising

theories in a way which can be used by a system

– represent domain-independent dialogue management strategies

TrindiKit features

TrindiKit features cont’d

• resources– represent domain-specific knowledge– can be switched dynamically

• e.g. switching language on-line in GoDiS

• modular architecture promotes reuse– basic system -> genre-specific systems– genre-specific system -> applications

TrindiKit and VoiceXML

• VoiceXML– industry standard– form-based dialogue manager– web/telephony infrastructure– requires scripting dialogues in detail

• Theory-specific?– VoiceXML implements a specific theory of

dialogue– TrindiKit allows implementation of several

different theories of dialogue– More complex dialogue phenomena hard to deal

with in VoiceXML

TrindiKit and VoiceXML, cont’d

• Combine VoiceXML with TrindiKit?– future research area – support connecting TrindiKit to

VoiceXML infrastructure– use TrindiKit system as VoiceXML

server, dynamically building VoiceXML scripts

– convert VoiceXML specifications to e.g. GoDiS dialogue plans

availability• version 2.1 is available• version 3.0a coming at end of 2002

– SIRIDUS deliverable D6.4

• TrindiKit website– www.ling.gu.se/projects/trindi/trindikit

• SourceForge project– development versions available– developer community?

• licensed under GPL• more info in

– Larsson & Traum: NLE Special Issue on Best Practice in Dialogue Systems Design, 2000

– TrindiKit manual (available from website)

Conclusions: TrindiKit & Information State Approach

• a toolkit for dialogue systems R&D• freely available to researchers• close the gap between theory and

practive of dialogue systems• theory-independent• promotes reuse and

reconfigurability on multiple levels

Flexible issue-based dialogue management

in GoDiS

Staffan LarssonGöteborg University

Sweden

Goals

• explore and implement issue-based dialogue management– adapt an existing semi-computational theory of

dialogue (Ginzburg’s KOS) to dialogue system (GoDiS) and implement

– extend theory (incl. accommodation, action-oriented dialogue, negotiation, conditional responses)

• separating general and domain-dependent phenomena helps reconfigurability– general theory of dialogue, extended into

subtheories for different dialogue types– minimize effort for adapting to new domains

TrindiKit

GoDiS

GoDiS-I GoDiS-A

TravelAgency

Auto-route

Xeroxmanual

VCRmanager

IBDM

homedevice

manager

ISapproach

genre-specific

application-specific

Basic issue-based dialogue management

• GoDiS-I: enquiry-oriented dialogue – typically, database search

• dialogue as raising and addressing issues

• dialogue plans to drive dialogue– each plan associated with a ”task question”

• deals with multiple simultaneous issues• enables information sharing between

plans

Multiple issues and information sharing

• user can switch freely between any number of tasks– e.g. set the clock while programming the VCR

• information collected while doing task A can be used in task B– e.g. where the user wants to travel; can be used for

travel reservation, visa enquiries, hotel reservation etc.

• this is a consequence of keeping a global information state, rather than task-local states (as in e.g. VoiceXML)

Sample dialogue: multiple tasks & info sharing

S> Welcome to the travel agency! U> price information S> (…) Lets see. How do you want to travel? U> by flightS> (…) What city do you want to go to? U> parisS> (…) What city do you want to go from? U> do I need a visa ?S> (…) Lets see. What country are you from? U> swedenS> Okay. Yes, you need a Visa. S> Returning to the issue of price. Lets see. What city do

you want to go from?

Grounding and feedback

• grounding– making sure that the participants are percieving,

understanding, and accepting each other’s utterances

– dealing with problematic situtations where e.g. an utterance is not percieved

• feedback– (short) utterances which signal grounding status of

previous utterance– in addition, utterances which signal switching task

(”returning to…”), reraising questions (”so…”) etc.

Question Accommodation

• to deal with – user giving more/less/other information than requested– simple information revision– reraising issues

• basic idea:– move questions to QUD or ISSUES to adapt to user

utterances– e.g. short answers where question can be found in the

context– generate clarification question if necessary

• more powerful than corresponding mechanisms in VoiceXML

Sample dialogue: accommodation

S: Welcome to the travel agency.U: From London to Paris in April

– not relevant to any question that has been raised, or to any current task

– look in domain knowledge for a plan (for dealing with some question Q) with matching questions

– load this plan, push Q on ISSUES– find in the plan the question(s) matching the user’s answer– integrate answer (requres matching question on ISSUES)

S: Alright, you want to know about price. (…)

– proceed to next plan item

S: How do you want to travel?– ISSUES=<?x.how(x), ?x.price(x)>

Action-oriented dialogue based on menus

• GoDiS-A: adapted for the genre of action-oriented dialogue

• each plan now associated with an action or a question

• semi-automatic conversion of menus to dialogue plans

• sample domain: menu-based dialogue for VCR

Sample menu dialogue(with language change!)

S: Welcome to the VCR manager. Let’s see. What can I do for you?

U: Add a program today, channel five– request(add_program) -> plan is loaded– issue accommodation to integrate ”channel

five”

…S: What time do you want to start recording?U: Five fifteen…

Conclusions: GoDiS & Issue-Based Dialogue Management

• general solutions to– dealing with multiple tasks– sharing information between tasks– grounding and feedback– user initiative (accommodation)– menu-based dialogue– negotiative dialogue (not yet implemented)

• rapid prototyping of applications– dialogue plans

• switching language online

end

Other architectures

• Agent communication protocols– Open Agent Architecture– KQML

• Dialogue system toolkits– DARPA Communicator– SOAR, NL-SOAR

• Systems (implementing specific dialogue theory)– Verbmobil– VoiceXML

• have been compared to TrindiKit (see deliverables or ask)

relevant properties

• support for information state approach– which datastructures/datatypes are

supported?

• support for managing control flow– not limited to pipelining

• asynchronous processing• modularity• potential for scalability

OAA

• ”Facilitator” (hub) manages communication between ”agents” (spokes)

• facilitator can maintain global information state– what datastructures are available?

• asynchronous processing• modular• similar to scriptless version of DARPA

Communicator

KQML

• Knowledge Querying and Manipulation Language

• communication protocol between agents

DARPA Communicator

• Hub-and-spoke architecture• modularity, flexible control,

asynchronous processing• hub functions

– message routing between servers (spokes)– state maintenance– control flow; script decides which server to

call next

DARPA communicator cont’d

• limited support for information states– ”tokens”: frames with name, index, and list

of feature-value pairs– tokens processed by scripts

• set of rules determining when to call a server + which arguments (features) to pass

• Hub scripts too limited to do real dialogue management– most actual systems have separate

dialogue manager– hub mostly used for data routing

SOAR

• toolkit for modeling cognitive agents• similar to TrindiKit in some respects• keeps single information state

– however, only one datastructure whereas TrindiKit has extendible range of (possibly complex) datatypes

• update rules– some nice ways of triggering rules which can be

considered for TrindiKit

• supports ”chunking” of rules– however, may not be too useful in practice

Verbmobil

• not dialogue system per se– rather, dialogue translation system

• several local information states, not one global – ”partitioned blackboard”– which datastructures? extendible set?

• limited control support