TrindiKit

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
TrindiKit architecture

• 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

4

control

DME
input
inter- pret
update
select
gene- rate
output

Information State
device manager
device
device interface
lexicon
domain knowledge
5
TrindiKit components

• 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

6
TrindiKit components (contd)

• 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.
  

7

Building a system

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

• 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

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
TrindiKit Features

• 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.)

11
Features, contd

• 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
Systems developed using TrindiKit

• 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

15
GoDiS

• An experimental dialogue system built using the
  TrindiKit

16
GoDiS features

• Information-seeking dialogue
• Information state based Ginzburgs 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

17
Sample GoDiS information state

AGENDA findout(?return)
findout(??x.month(x)) findout(??x.class(x))
respond(??x.price(x))
PRIVATE
PLAN
BEL
TMP (same structure as SHARED)
dest(paris) transport(plane)
task(get_price_info)
COM
SHARED
QUD lt ?x.origin(x) gt
LM ask(sys, ?x.origin(x))

18
Sample update rule

• integrateAnswer
• Before an answer can be integrated by the
  system, it must be matched to a question on QUD

in(SHARED.LM, answer(usr, A)) fst(SHARED.QUD, Q)
relevant_answer(Q, A)

pre
pop(SHARED.QUD) reduce(Q, A, P)
add(SHARED.COM, P)

eff
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

in(SHARED.LM, answer(usr, A))
in(PRIVATE.PLAN, findout(Q))
relevant_answer(Q, A)
pre
delete(PRIVATE.PLAN, findout(Q)) push(SHARED.QUD,
Q)
eff
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
GoDiS features (contd)

• 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 -gt
  Stina)
• Simple optimistic grounding strategy
• Focus intonation based on information state
  contents
• Also being extended to handle negotiative
  dialogue (SIRIDUS)