GoDiS

1. GoDiS AI-course, Chalmers April 22, 2002 Staffan Larsson

2. this lecture • introduction to GoDiS • information state • moves, plans, actions • accommodation • optimistic grounding and acceptance • information-oriented vs. action oriented dialogue • command dialogue & menus • instructional dialogue & text

3. GoDiS features • originally: information-seeking dialogue • extended to action-oriented 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

4. GoDiS & TrindiKit domain-specific GoDiS system domain & language resources QUD-based dialogue theory (IS, rules, ...) generic GoDiS system TrindiKit information state approach

5. control DME input inter- pret update select gene- rate output • TIS • IS proper • 5 module interface variables • 3 resource interface variables • DATABASE LEXICON DOMAIN data- base lexicon domain knowledge

6. basic GoDIS infostate type AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move ) + module interface variables INPUT : String LATEST-MOVES: Set(Move) LATEST-SPEAKER: Speaker NEXT-MOVES: Set(Move) OUTPUT: String + resource interface variables LEXICON : Lexicon DOMAIN : Domain DATABASE : Database

7. 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-city(paris) transport(plane) task(get_price_info) COM = SHARED = QUD = < x.depart-city(x) > LU =SPEAKER= sys MOVES ={?x.depart-city(x)) - false}

8. Activity-based moves in GoDiS • Moves are determined by the relation of the content to the domain • utterance U is an answer if the content A of U is a relevant answer to a question Q in the domain • moves are not necessarily speech acts! • GoDiS basic dialogue moves • ask(Q), Q:question • answer(A), A:answer (proposition or fragment) • inform(P), P:proposition • request-repetition • greet, quit

9. 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) $DOMAIN:relevant_answer(Q, A) pre: pop(SHARED.QUD) DOMAIN: reduce(Q, A, P) add(SHARED.COM, P) eff:

10. Dialogue plans • domain-specific • partial specifications of how the system should act in a dialogue • specifies default behaviour • may be overridden by user initiative • operational semantics of plan constructs • determined by information state update rules

11. Dialogue plan constructs • action A • exec(S) • S is a task/subplan • sequence <C1,C2,..., Cn> • if P then C • P is a proposition and C a construct • If P is (believed to be) true, execute C • case(<P1, C1>, ...,<Pn-1, Cn-1>, Cn)

12. Actions • findout(Q): find the answer to Q • raise(Q): raise Q • respond(Q): provide answer to Q if there is one in the private beliefs • inform(P): inform of P • (Q is a question, P a proposition)

13. Questions • y/n-question: ?P • ”Do you want a return ticket?” • ”Do you want to call NN?” • wh-question: ?x.P(x) • “What city do you want to go to?” • ”Who do you want to search for?” • alt-question: {?P1, ?P2, ..., ?Pn} • ”Do you want to search, add to, erase from or change the phonebook?”

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

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

16. Dialogue plan, formal representation • findout(?x.transport(x)) • findout(?x.dest-city(x)) • findout(?x.depart-city(x)) • findout(?return) • … • consultDB(?x.price(x)) • respond(?x.price(x))

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

18. Accommodation • Lewis (1979): • If someone says something at t which requires X to be in the conversational scoreboard, and X is not in the scoreboard at t, then (under certain conditions) X will become part of the scoreboard at t • A: My cat is hungry • B accommodates “A has a cat” • Has been applied to referents and propositions, as parts of the conversational scoreboard / information state

19. 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, • then, push 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

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

21. question accommodation… AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move )

22. Task accommodation • In some cases, the system may not even know what task the user wants the system to perform • If latest move was an answer, and there is currently no plan, • find (in the domain resource) a task and corresponding plan containing a matching question; • accommodate the task and load the appropriate plan • Similar to plan recognition, but no dynamic plan reconstruction or assumption that the full plan is shared

23. Update rule for task accommodation taskAcc - An answer move matches a task if the plan contains a question matching the answer - More complex version generates clarification question if the number of plans > 1 in($SHARED.LM, Move) $DOMAIN:: match_task(Move, Task, Plan) pre: add(SHARED.BEL, task(Task)) set(PRIVATE.PLAN, Plan) eff:

24. task accommodation… • DATABASE= LEXICON = DOMAIN= • travel travel_english travel AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move ) database travel lexicon travel english domain travel

25. 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?

26. An optimistic approach to grounding • DPs assume their utterances are understood • If A asks a question with content Q, A will update SHARED.LM with ask(A,Q) • If addressee indicates that the previous utterance was not understood (reqRep), backtrack • uses the PRIVATE.TMP field, which contains a copy of the SHARED field from before the latest utterance was made • The alternative is a pessimistic approach • If A asks Q, A will not update SHARED.LM until B indicates understanding (implicitly or explicitly)

27. Update rule for optimistic grounding • assumeSysMovesGrounded pre: $LATEST-SPEAKER == sys • SHARED.LU.SPEAKER := sys • clear( SHARED.LU.MOVES ) • forall_do( in( LATEST-MOVES, Move), • add( /SHARED/LU/MOVES, Move, false) ) eff:

28. optimistic grounding input inter- pret update select gene- rate output INPUT : String OUTPUT: String LATEST-MOVES: Set(Move) LATEST-SPEAKER: Speaker NEXT-MOVES: Set(Move) AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move )

29. Optimistic approach to acceptance • DPs assume their utterances are accepted (and integrated into SHARED) • If ask(A,Q) is in SHARED.LM, A will make Q topmost on SHARED.QUD • If addresse indicates rejection, backtrack • using the PRIVATE.TMP field • No need to indicate acceptance explicitly; it is assumed • The alternative is a pessimistic approach • If A asks a question with content Q, A will wait for an acceptance (implicit or explicit) before putting Q on top of QUD

30. optimistic acceptance AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move )

31. GoDiS features • Adapted for travel agency and autoroute domains, as well as acting as interface to handheld computer or mobile phone • Question and task accommodation to enable mixed initiative • Simple “optimistic” grounding strategy • Focus intonation based on information state contents • Has been extended to handle instructional dialogue (IMDiS) • Also being extended to handle negotiative dialogue (SIRIDUS)

32. Action- and information-oriented dialogue

33. Information- vs. action-oriented dialogue • Information oriented dialogue (IOD) has the primary goal of exchanging information, regardless of how this information will be used in future actions • Action oriented dialogue (AOD) has the primary goal of one or several participants performing or being obliged to perform an action (or plan, i.e. a complex action)

34. Information-oriented dialogue • Information-seeking dialogue (ISD): one DP asks the questions, the other answers them • Information-exchange (information oriented) dialogue: both DPs ask questions and provide answers • IOD can be seen as a sequence of infoseeking dialogues, possibly with embedded subdialogues • shared information is stored in shared.com

35. Action-oriented dialogue • In simple AOD, only one participant becomes obliged/comitted to some action or plan • Actions can either be performed ”online” while the dialogue is happening, or they may be stored as a plan to be performed after the dialogue (”offline”) • Requires a store of obliged actions in the IS (SHARED.ACTIONS) • Two subtypes; • instructional dialogue • command dialogue

36. GoDIS AOD-extended infostate type AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) ACTIONS : stack( Action ) SHARED : QUD : stack( Question ) LU:…

37. Menu-based natural command dialogue (D’Homme) • system carries out actions • conversion menu 2 dialogue • menu-based interfaces can be automatically or semi-automatically converted into dialogue plans • flexible dialogue • dialogue plans are used in a way that enables more flexible interaction than the original menu-based interface • Larsson, Cooper, Ericsson (2001): menu2dialog. IJCAI workshop paper.

38. Menus vs. dialogue:Drawbacks of menus • User must follow predesigned menu structure • this structure may be complicated and difficult to learn • menus allow only one activity at a time

39. Menu vs. dialogue:Advantages of flexible dialogue • provide information in any order • provide information without pre-specifying the task • not necessary to learn menu structure • doing several things at once

40. Menu components • multiple-choice list • the user selects one of several prespecified choices • dialogue window • user types requested information • tickbox • user ticks box (or not) • system message • information from system; user clicks ”OK”

41. Sample menu from a Nokia 3210 mobile phone • search phonebook • dialogue window to type in name • Name: _______ • message showing the number • Kalle 031 12 34 56 • tickbox: whether to call this person • Call? • if a call is made, a message: • Calling 031 12 34 56

42. Converting menus to plans

43. Converting menus to plans, cont’d • in addition, we need • if-then statements to check conditions and pick out propositions • device actions, e.g. • “call up number N” • “add name N with number M to phonebook” • … • these are not currently assumed to be part of the menu specification

44. the menu again • search phonebook • dialogue window to type in name • Name: _______ • message showing the number • Kalle 031 12 34 56 • tickbox: whether to call this person • Call? • if a call is made, a message: • Calling 031 12 34 56

45. Corresponding plan findout(?x.name(x)); lookup_database(?x.number(x)); if number(N) then respond(?x.number(x) ), findout( ?call ), if call and name(M) then inform(calling_name(M))))

46. Another plan: change ringtone findout(?x.name(x)); findout(?x.ringtone(x)); if name(N) and ringtone(R) then save-ringtone( N, R ), inform(ringtone-changed);

47. Example 1: standard menu navigation U:Go to the phonebook S: Phonebook. Do you want to search, add, or remove an entry, or assign a ringing tone? U: Assign ringing tone S: What name? U: John S: Which ringtone? U: Bossanova S: The ringtone for John is now Bossanova.

48. Example 2: question accommodation U: Assign ringtone S: What name? U: Bossanova for John accommodate ”which ringtone?” S: The ringing tone for John is now Bossanova.

49. Example 3: task accommodation U: Bossanova for John accommodate task: assign ringtone accommodate ”which ringtone?” accommodate ”what name?” S: The ringing tone for John is now Bossanova.

50. Example 4: task clarification U: 5 o’clock • matches two tasks; ask for clarification S: Do you want to set the clock or the alarm clock? U: alarm clock • accommodate ”what time?” S: the alarm clock is now set to 5