1

Issue-based dialogue management

Staffan LarssonArbetsseminarium 26/2-02

2

overview of thesis contents

1. Introduction2. The information state approach and TrindiKit3. Basic issue-based dialogue management4. Meta-issues and grounding5. Adressing unraised issues6. Issues and goals in action-oriented dialogue7. Issues Under Negotiation8. Conclusions

3

1. Introduction; goals of thesis• explore and implement issue-based dialogue

management– starting from Ginzburg’s theory and other relevant theories– adapt to dialogue system and implement– extend theory (incl. accommodation, action-oriented

dialogue, negotiation)

• separate general and domain-dependent phenomena– theoretical: general theory of dialogue– practical: minimize effort for adapting to new domains

• incrementally extending system to handle increasingly complex types of dialogue– theoretical: clarifies relation between dialogue types – practical: reuse of update rules

4

3. Issue-based dialogue management

• enquiry-oriented dialogue (database search)• basis:

– Ginzburg’s Dialogue Gameboard (DGB) and – related DGB update protocols

• moves: ask, answer, greet, quit• raising and addressing issues

– incl. short answers. e.g.”yes”, ”no”, ”paris”, ”in april”

• dialogue plans• sample domain: travel agency• extension:

– reraising issues– handling multiple issues

5

Semantics

• ”FOL” without quantifiers,disjunction,conjunction

• Questions– Y/N-questions: ?P, P is a proposition– wh-questions: ?x.p(x)– alt-questions: {?P1, …, ?Pn}

• Content of short answers– individual markers: paris, april, …– yes, no

6

Semantics, cont’d

• Q-A relations (adapted from Ginzburg)– resolves(A,Q): A resolves Q

• dest-city(paris) resolves ?x.dest-city(x)

– about(A,Q): A is about Q (relevant to Q)• not(dest-city(paris)) is about ?x.dest-city(x), but

does not resolve it

– goal-fulfilling(P, ): comittment to proposition P fulfils the goal of action

• dest-city(paris) is goal-fulfilling w.r.t. findout(?x.dest-city(x))

7

basic infostate

PRIVATE :PLAN : stack( Action ) AGENDA : OpenQueue( Action )

SHARED :

BEL : set( Prop )

COM : set( Prop ) QUD : stack( Question )

LU: SPEAKER: Speaker MOVES: OQueue( Move )

+ module interface variablesINPUT : StringLATEST-MOVES: Set(Move)LATEST-SPEAKER: Speaker

NEXT-MOVES: Set(Move)OUTPUT: String

+ resource interface variablesLEXICON : LexiconDOMAIN : DomainDATABASE : Database

8

sample dialogue plan

• findout(?x.transport(x))• findout(?x.dest-city(x))• findout(?x.depart-city(x))• findout(?x.dept-month(x))• findout(?x.dept-day(x))• findout({?class(economy), ?class(business)}

• consultDB(?x.price(x))• respond(?x.price(x))

9

Answer integration

• integrateAnswer

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

pre:

eff:

in($SHARED.LU.MOVES, answer(A)) fst($SHARED.QUD, Q) $DOMAIN:about(A, Q)

DOMAIN: combine(Q, A, P) add(SHARED.COM, P)

10

basic dialogue with updates

U: ”how much does a trip cost?”– if user asks Q, push respond(Q) on AGENDA– if respond(Q) on AGENDA and PLAN empty, find plan

for Q and load to PLAN– if findout(Q) first on PLAN, ask Q

S: ”where do you want to go?”U: ”Paris”

– if LM=answer(A) and A about Q, add P=Q[A] to SHARED.COM

– if P in SHARED.COM and Q topmost on QUD and P resolves Q, pop QUD

– if P in SHARED.COM and P fulfils goal of findout(Q) and findout(Q) on PLAN, pop PLAN

11

basics cont’d

• …S: ”what class did you have in mind?”U: ”cheap”

– if consultDB(Q) on PLAN, consult database for answer to Q; store result in PRIVATE.BEL

– if Q on QUD and P in PRIVATE.BEL s.t. P resolves Q, answer(P)

S: ”The price is £123”

12

Information sharing across plans

• ISIS does not keep track of when propositions were added, or which plan was being executed

• so information sharing is determined by question sharing across plans

• plan for VISA question:findout(?x.dest-city(x))findout(?x.citizenship(x))– shares a questions with plan for ?x.price(x)

• so if visa-issue raised after price-issue, no need to ask for destination again

13

Variation: dealing with multiple issues

• if user asks Q, push Q on QUD and load plan for dealing with Q

• if users asks Q’ while system is dealing with Q, throw out plan for Q but Q remains on QUD

• when Q’ resolved, Q topmost on QUD will trigger reloading plan for dealing with Q– general rule: if SHARED.COM contains info resolving

Q, don’t ask Q– so any resolved questions in plan will be thrown out

14

Sample dialogue

U: I want price information [raise ?x.price(x)]S: Where do you want to go? U: LondonS: When do you want to travel?

QUD=<?x.dept-month(x), ?x.price(x)>U: Do I need a Visa? [raise ?visa]

QUD=<?visa, ?x.dept-date(x), ?x.price(x)>S: Where are you travelling from?U: GothenburgS: No, you don’t need a Visa.

QUD=<?x.dept-month(x), ?x.price(x)>PLAN empty

15

Sample dialogue, cont’d

S: No, you don’t need a Visa.QUD=<?x.dept-date(x), ?x.price(x)>

U: OK, I want to leave in April [answer dept-month(april)] QUD=<?x.price(x)>PLAN empty, so reload plan for dealing with ?x.price(x)Throw out all question which have already been resolved; raise the first unresolved question on plan

S: What day do you want to leave?…

16

Variation: limited inference and vagueness

• answers that need inference to determine aboutness – can be regarded as ”vague”– the relation to a question is vague– many different inferences may do the job equally

well)

• about is agent-related since it relies on inferential capabilitites (contra Ginzburg)– in DOMAIN: P is about Q if P’->Q and P’ about Q

• example: dest-country(france) is about ?x.dest-city(x) if dest-city(paris)->dest-country(france)

– not(P) is about Q if P is about Q

17

inference and resolution

• backward-chaining inference– relation on Set(Prop): ”provable(Prop,

Set(Prop))”– Prop extended to include implication

• Modus Ponens – provable(P,S) if Q->P in S and provable(Q,S) – resolves(P,Q) if P->P’ and resolves(P’,Q)

• Negation• Closed World Assumption

– APPL-INST(?x.P(x))={P(a)|sort-restr(P(a))}

18

4. Meta-issues, grounding, and feedback

• feedback types– action level: contact, perception, understanding,

acceptance/integration– polarity: positive, negative– eliciting/non-eliciting– form: declarative, interrogative, imperative, elliptical– content: none, metalevel, object level

• update strategies– optimistic

• non-cautious• cautious

– pessimistic

• feedback and grounding for a dialogue system

19

Feedback polarity

• polarity: positive, negative• eliciting/non-eliciting• Examples

– ”What do you mean?”• negative, eliciting

– ”Do you mean that the destination is Paris?”• ??negative??, eliciting

– ”To Paris.”• positive, non-eliciting

– ”Pardon?”• negative, ???eliciting??

20

Feedback polarity cont’d

• simplifying assumptions– positive fb is never eliciting

• ”To Paris?” is neutral

– netral feedback is always eliciting

• Polarities:– positive, non-eliciting: pos– negative

• non-eliciting: neg• eliciting: negelc

– neutral, eliciting: elc

21

ICM dialogue moves

• Interactive Communication Management– feedback– sequencing– turntaking

• icm:Level{*Polarity}{:Content}– icm:und*neg – ”I don’t understand”– icm:und*negelc – ”What did you say?”, ”Pardon?”– icm:und*elc:AltQ – ”Do you mean x or y?”– icm:und*pos:P – ”To Paris.”– icm:acc*neg:Q – ”Sorry, I can’t answer Q”– icm:acc*pos – ”Okay”– icm:reraise:Q – ”Returning to the issue Q” [sequencing

ICM]

22

Realisation of ICM dialogue moves

• Form:– declarative: ”I didn’t hear what you said.”; ”The

destination city is Paris.”– interrogative: ”What did you say?”; ”Do you want to go to

Paris?”– imperative: ”Please repeat your latest utterance!”– elliptical

• interrogative: ”Paris?”, ”To Paris or from Paris?”• declarative: ”To Paris.”

• Content:– object-level: ”To Paris?”, ”Do you want to go to Paris?”– metalevel: ”Did you mean you want to go to Paris?”

• eliciting is always interrogative (possibly elliptical)

23

Implicit feedback

• Clark: ”relevant followup” to U– what is relevant?

• simple cases for followups to questions:– answer to question– ”subquestion”

• in general, complex inference and knowledge may be needed (implicatures)

– counts as positive feedback?– irrelevant followup counts as negative?

• What about no followup at all?

24

System feedback for user utterances

• contact– negative (”I didn’t hear anything from you.”)

• perception– negative: fb-phrase (”Pardon?”, ”I didn’t hear what you said”)– positive: repetition (”I heard ’to paris’”)

• understanding– negative: fb-phrase (”I don’t quite understand”)– positive: reformulation (”To Paris.”)– eliciting neutral: reformulation (”To Paris, is that correct?”, ”To

Paris?”)• acceptance/integration

– negative:fb-phrase with reformulation (”Sorry, I cannot answer Q”, ”Sorry, Paris is not a valid destination city.”)

– positive: fb-word (”okay.”)

25

User feedback for system utterances

• contact: -• perception

– negative: fb-phrase (”Pardon?”, ”I didn’t hear what you said”)

• understanding: -• acceptance/integration

– negative: fb-phrase (”I don’t know”, ”Never mind”)– positive: fb-word (”okay.”)

26

Feedback: action levels and associated metaissues

• assume A uttered U to B– A and B are faced with a number of issues

• contact: do A and B have contact?• perception:

– A: does B percieve U (correctly)?– B: what did B say? / Did B say V?

• understanding: – A: does B understand U (correctly)– B: what did B mean? / Did B mean C?

• acceptance– A: does B accept U– B: should I accept U?

27

Grounding and action levels

• ”To ground a thing … is to establish it as part of common ground well enough for current purposes.” (Clark)

• grounding applies to all action levels• U is grounded on level L = the answer to the

grounding issue on level L is positively resolved• grounding assumptions correspond to

information state updates in system– contact, perception not explicitly modeled– understanding: SHARED.LU.MOVES– acceptance: SHARED.QUD, SHARED.COM

28

Grounding update strategies

• strategic questions:– When should U assumed to be grounded on level L?

• as soon as it has been uttered (of course, the hearer cannot assume grounding until grounding wh-issues have some answer, e.g. ”what did A say?” )

• if B does not give negative feedback• when B gives positive feedback• when B has given eliciting feedback which has been

confirmed by A– What to do if the grounding assumption turns out to be

mistaken

• optimism on level L:– assume U is grounded on level L as soon as U has

been uttered

29

Grounding update strategies cont’d

• optimism on level L:– assume U is grounded on level L as soon as

U has been uttered

• cautious optimism:– make sure the optimistic assumption can

easily be retracted

• pessimism:– don’t assume U grounded until there has

been some positive feedback (or at least no negative feedback)

30

Meta-issue: understanding

• Ginzburg’s content question– ?x.content(LU,x)– ”What’s the meaning of LU?”

• understanding-issue– for speaker who uttered LU with move type

m, content c– or hearer who interpreted LU– ?und(m(c))– ”Is m(c) a correct interpretation of LU?

31

Optimistic approach to grounding

• assumption that answer to grounding questions are positive

• for system utterances– need to deal with cases where user indicates

optimistic assumption is wrong– at least for perception and acceptance levels

• for user utterances– need to indicate failure, and on which action

level– if fail to understand or accept, don’t modify

SHARED

32

optimistic understanding update

input

inter-pret

update selectgene-rate

output

PRIVATE :PLAN : stackset( Action ) AGENDA : Queue( Action )

SHARED :

BEL : set( Prop ) TMP : (same type as SHARED)

COM : set( Prop ) QUD : stack( Question )

LU: SPEAKER: Speaker MOVES: OQueue( Move )

LATEST-MOVES: Set(Move) LATEST-SPEAKER: Speaker

33

Meta-issue: acceptance

• Ginzburg’s protocols for acceptance • LM = ask Q -> consider ?MAX-QUD(Q)

– if yes, push Q on QUD– otherwise, address ?MAX-QUD(Q)

• LM = assert P -> consider ?MAX-QUD(?P)– if yes, consider ?P

• if yes, add P to FACTS• otherwise, address ?P

– otherwise, address ?MAX-QUD(?P)

34

rejections

• ?MAX-QUD(Q) is answered ”no”– inability to answer Q

• ”Sorry, I can’t answer that question”– unwillingness to answer Q

• ”I don’t want to discuss that”

• ?MAX-QUD(?P) is answered ”no”– unwillingness to discuss whether ?P

• ”I don’t want to discuss that”– other reasons?

• ?P answered ”no”– ”Sorry, I don’t agree.”, ”You’re wrong!”, ”That’s

impossible!”– can be expected to lead to argumentation

35

problematic cases

S: ”Where do you want to go?”U1: ”Nowhere”U2: ”I don’t know”U3: (silence) OR ”I want first class!”

• do these count as rejections?– U1: negative answer? presupposition failiure?

rejection?– U2: rejection?

• but not as definite as ”No comment!”

– U3: rejection? • in any case, irrelevant followup

36

optimistic acceptance update

PRIVATE :PLAN : stackset( Action ) AGENDA : stack( Action )

SHARED :

BEL : set( Prop ) TMP : (same type as SHARED)

COM : set( Prop ) QUD : stack( Question )

LU: SPEAKER: Speaker MOVES: assocSet( Move )

37

choice of strategies in system

• system utterances– optimistically assumed to be grounded on all levels– negative feedback on perception or acceptance levels ->

backtrack to saved state• user utterances

– if problem on any level, give negative fb– if OK on all levels, update strategy and feedback determined

by recognition score– S > 0.9

• optimistic update, icm:acc*pos– 0.9 >= S > 0.8

• optimistic update, icm:acc*pos, icm:und*pos:Content– 0.8 >= S >0.5

• pessimistic update, ask(?Content)• if ?Content recieves answer ”yes”, add assume Content grounded

38

optimistic acceptance

• assume positive answer to ?MAX-QUD(Q)• assume positive answer to ?MAX-QUD(?P) and ?P• we don’t need to represent these issues explicitly• for system utterances

– need to deal with cases where user indicates optimistic assumption is wrong

– so far, only for system questions

• for user utterances– need to indicate when optimistic assumption is wrong– both questions (sys has no plan) and propositions

(invalid database parameter)

39

5: Addressing unraised issues

• ISSUES and QUD• answer integration• question accommodation (to QUD)• issue accommodation (to ISSUES)• reraising issues• multiple issues: modified account• information sharing across plans• reacommodation (reraising by accomm.)• transitive reaccommodation and reraising

40

problem with QUD

• If QUD=<q1,q2> and q1 is resolved, q2 is available for resolution of short answers– takes no account of how many turns since

q2 was raised– but short answers a long distance away

from the question are not as easily processed as an adjacent answer

41

ISSUES and QUD

• We extend Ginzburg’s DGB by adding ISSUES of type Stack(Question)

• ISSUES contains all raised but unresolved questions – ISSUES determines relevance of user answers

• QUD used for resolving short answers– questions drop off QUD after N turns– a short answer to a question that’s on ISSUES

but not QUD requires QUD accommodation!

42

short answer integration

• If– LM=answer(A); A is a short answer– Q topmost on QUD– A about Q

• then– P = Q[A]– add P to SHARED.COM

• QUD downdate: if Q topmost on QUD and P in SHARED.COM s.t. resolves(P,Q), pop QUD

43

full answer integration

• If– LM=answer(A); A is a proposition– Q in ISSUES– A about Q

• then– add A to SHARED.COM

• Issue downdate: if Q on ISSUES and P in SHARED.COM s.t. P resolves Q, remove Q from ISSUES

44

issue accommodation PLANISSUES

• If – LM=answer(A) – no Q in ISSUES s.t. about(A,Q)

• then– find findout(Q) in PLAN s.t. about(A,Q)– push Q on ISSUES

• used when prevously unraised question (available in plan) is answered using a short or full answer

45

question accommodation ISSUESQUD

• If – LM=answer(A)– no Q in QUD s.t. about(A,Q)

• then– find Q in ISSUES s.t. about(A,Q)– push Q on QUD– raise Q in ISSUES (make Q topmost)

• used when– previously raised question has dropped off QUD, but

is answered using a short answer– previously unraised question is answered using short

answer [needs PLANISSUES accommodation]

46

transitive issue accommodationDOMAINISSUES (+PLAN)

• If – LM=answer(A)– no Q in ISSUES s.t. about(A,Q)– no findout(Q) in PLAN s.t. about(A,Q)

• then– find Plan for some Q’ in DOMAIN s.t. findout(Q) or

raise(Q) in Plan and about(A, Q)– push Q’ on ISSUES– set PLAN to Plan

• used when previously unraised question, unavailable in PLAN, is answered using full or short answer

47

Question reraising selection ISSUESQUD

• if– Q on ISSUES– Q not on QUD– PLAN empty– system has no plan for dealing with Q

• then– set next move to ask(Q)

• assumption: questions on QUD have more attention than those merely on ISSUES

• Need to deal with state where Q is topmost on ISSUES but not on QUD; this indicates Q needs to be reraised

• NOTE: this is a selection rule

48

dealing with multiple issues: modified account

• if user asks Q, push Q on ISSUES and load plan for dealing with Q

• if user asks Q’ while system is dealing with Q, throw out plan for Q but Q remains on ISSUES

• when Q’ resolved, any Q’’ on ISSUES but not on QUD will be reraised by system

• After this, Q will be dealt with by reloading plan

49

Sample dialogueS: helloU: London please• transitive issue accommodation: push on ISSUES ?x.price(x)• load plan for ?x.price(x) • issue accommodation: push on ISSUES ?x.dest-city(x)• question accommodation: push on QUD ?x.dest-city(x)• integrate answer

S: What month do you want to travel?ISSUES=<?x.dept-month(x), ?x.price(x)>

U: Do I need a Visa? [raise ?visa]ISSUES=<?visa, ?x.dept-month(x), ?x.price(x)>

S: Where are you travelling from?U: GothenburgS: No, you don’t need a Visa.

ISSUES=<?x.dept-month(x), ?x.price(x)>PLAN empty; QUD empty

50

Sample dialogue, cont’d

S: No, you don’t need a Visa.ISSUES=<?x.dept-date(x), ?x.price(x)>PLAN empty; QUD emptyreraise ?x.dept-date(x)

S: What month do you want to leave?U: April

ISSUES=<?x.price(x)>PLAN empty, so reload plan for dealing with ?x.price(x)Throw out all question which have already been resolved; raise the first unresolved question on plan

S: What day do you want to leave?U:

51

pros and cons of this solution

• Inefficient since system does not keep track of where it was in the plan before it was thrown out

• No way of knowing which issue is currently being dealt with, and thus whether a new plan should be loaded– possible solution: guarantee that plan always concerns topmost

Q on ISSUES• Alternative solution is to keep unfinished plans around

– PLAN : Stackset(Pair(Question, Plan))• However, going through the plan again may be useful in case

e.g. some information was removed when dealing with the embedded issue

• Possible solution is to keep track of overlap between plans– if Q’ is raised while dealing with Q, and the plans overlap, throw

out plan for Q and reload it later– otherwise, keep partially executed plan for Q around

52

Issue reraising SHARED.COMISSUES

• If – LM=ask(Q)– there is a P in SHARED.COM s.t. about(P,Q)

• then– push Q on ISSUES– remove P from SHARED.COM

• used when previously resolved question is asked again

• reraising should be inicated; ”so,…”; reformulation may be needed

53

Issue reaccommodation SHARED.COMISSUES

• If – LM=answer(A) – no Q in ISSUES s.t. about(A,Q)– P in SHARED.COM s.t. there is a Q s.t.

about(A,Q) and about(P,Q)

• then– push Q on ISSUES– remove P from SHARED.COM

• Used when previously resolved question is answered again

54

a problem

• What if user, after system has given a price, changes his mind?

• I.e., a previously resolved question is answered again, and this question influences another resolved question

• Q influences Q’ if findout(Q) is in the plan for resolving Q’

• example:– ?x.dest-city(x) influences ?x.price(x)

55

Transitive issue reaccommodation

SHARED.COMISSUES • If

– LM=answer(A) – no Q in ISSUES s.t. about(A,Q)– there is a Q’ s.t. Q influences Q’– there’s a P in SHARED.COM s.t. about(A,Q) and about(P,Q)– P’ in SHARED.COM is about Q’

• then– push Q’ on ISSUES– remove P’ from SHARED.COM– push Q on ISSUES– remove P from SHARED.COM

• After this, A can be integrated into SHARED.COM, the plan for Q’ will be loaded and since all questions are already answered, the only result will be a new database search

56

sample dialogue

…S: When do you want to travel?U: In April…S: The price is £150

– ISSUES = <>

U: Hmm, what about June [answer(june)]– transtitive issue reaccommodation;– ISSUES=<?x.dep_month(x), ?x.price(x)>– integrate answer(june)– redo database search for ?x.price(x)

S: The price is £200

57

Assertions vs. answers

• answers provide information about a domain-related question– presupposes that such a question is on QUD

or ISSUES

• assertions adresses a general, slightly fuzzy, question– ”what is true?” or ”what shall we discuss?” or

similar– this question is not presupposed

• Systems usually don’t handle assertions in this sense

58

6: Issues and goals in Action-oriented dialogue

• each plan now associated with a goal action instead of a question

• add SHARED.GOALS : Stack(Action)• GOALS has a similar role to ISSUES

– Problem: how coordinate ISSUES and GOALS?

• New moves: request, acknowledge• adapt accommodation strategies to AOD• sample domains:

– travel agency ticket booking– menu-based dialogue for VCR– instructional dialogue

59

integrating requests

• If– L-M is request(A)– $DOMAIN: Plan(A, _Plan)

• then– push(SHARED.GOALS, A)

• (findPlan rule will load the plan)

60

Requests vs. answers

• requests adresses a general question– ”what shall I do next?”, ”what can I do for you?”

or similar (”prompt”)– semantics in AOD: ?x.action(x)– this question is not presupposed

• ”Search the phonebook” interpreted as request(search_phonebook)

• Rule: – If ?x.action(x) is topmost on ISSUES and L-M is

request(a)– then pop ISSUES

61

Questions vs. answers

• a question can be regarded as a special type of request

• so in a specific sense, questions are also answers…

• questions adresses a general question– ”what issue shall I address next?”, ”what can I

do for you?” or similar (”prompt”)– semantics: ?x.issue(x)– this question is not presupposed

• semantics of ”How can I help you?” in IOD is ask(?x.issue(x))

62

7: Issues under negotiation

• Sidner: a formal account of negotiative dialogue

• an alternative account based on Issues Under Negotiation

• proposals and alternative-questions• Acceptance, downshift, and negotiation• sample domain: travel agency,

negotiating flights

63

Negotiation vs. acceptance

• Clark’s ladder:– 1. A attends to B’s utterance– 2. A percieves B’s utterance– 3. A understands B’s utterance (grounding)– 4. A accepts or rejects B’s utterance

• Sidner and others sees negotiative dialogue as proposals and acceptance/rejections of proposals– this means that all dialogue is negotiative– all assertions (and questions, instructions etc.) are

proposals• But some dialogues are negotiative in another sense, by

explicitly containing discussions about different solutions to a problem, and finally deciding on one– Negotiation is not Clark’s level 4

64

Two senses of “negotiation”

• Negotiation in Sidner’s sense– A: I want to go to Paris [propose]– B(1): OK [accept]– B(2): Sorry, there are no flights to Paris [reject]

• Negotiation in our sense– U: flights to paris on september 13 please [answer]– S: there is one flight at 07:45 and one at 12:00

[propose]– U: what airline is the 12:00 one [ask]– S: the 12:00 flight is an SAS flight [answer]– U: I’ll take the 12:00 flight please [accept]

65

Issues Under Negotiation in (fully) negotiative

dialogue• IUN is question e.g. what flight to take• In an activity, some questions are

marked as negotiable issues– other questions are assumed to be non-

negotiable, e.g. the user’s name in a travel agency setting

• Each IUN is associated with a set of proposed answers– Needs a new IS field: SHARED.IUN of type

assocset(question,set(answer))

66

Alternatives in negotiation

• Alternatives are possible answers to an IUN• a proposal has the effect of introducing a new

alternative to the Issue Under Negotiation• An IUN is resolved when an alternative is

decided on, i.e. when an answer to it is accepted

• In some cases, the answer to IUN may consist of a set of alternatives (e.g. when buying CDs)

67

Example

• IUN is ?x.sel_flight(x) (“which is the chosen flight”?)

• A: flight to paris, december 13– answer(dest(paris)) etc.;

• B: OK, there’s one flight leaving at 07:45 and one at 12:00– propose(f1), propose(f2),– answer(dep_time(f1,07:45)), answer(dep_time(f2,12:00))

• ....• A: I’ll take the 07:45 one

– answer(sel_flight(X), dep_time(X, 07:45)),– after contextual interpretation: answer(sel_flight(f1))

68

PRIVATE =

PLAN =

AGENDA = { findout(?x.sel_flight(x)) }

SHARED =

findout((?x. ccn(x))book_ticket

COM = dep_time(f1,0745),dep_time(f2,1200)dest(paris), ...

QUD = <> LM = {propose(f1), propose(f2),

answer(dep_time(f1,07:40),...}

BEL = {flight(f1), dep_time(f1,0745), ... } TMP = (same structure as SHARED)

IUN = < ?x.sel_flight(x f1, f2 } >

B: OK, there’s one flight leaving at 07:45 and one at 12:00

69

Proposals and alternative-questions

• wh-question + proposals has same effect as asking alt-question– ”Do you want to travel in economy class or

business class?” [ask alt-q]– ”How do you want to travel? One option is

economy class. The other option is business class.” [ask wh-q; propose(economy), propose(business)]

• alternate representation of alt-q’s– {?P(a1), …, ?P(aN)}– ?x.P(x)-{a1, …, aN}– partial functions for format conversion

70

”Downshift”• original idea (Cohen 1978)

– ”gears” in dialogue: ”games per turn”• high gear = many latent subgames per turn

– originally used to describe shifting to e.g. referent identification subdialogues

– ”latent” referent identification game becomes manifest; c.f. finding answer to content-question

• extension to acceptance– If optimistic assumption of acceptance occurs, negotiation

may ensue– latent acceptance game becomes manifest– c.f. finding answer to acceptance questions– this is where an issue assumed to be non-negotiable turns

becomes negotiable

71

sample dialogue

A: Where do you want to travel?B: Paris [answer(paris)]

– B optimistically assumes dest-city(paris) in SHARED.COM

A: Sorry, there are no flights to Paris. How about Marseille or Lyons?– question is reraised and is opened for

negotiation; two proposals added– ISSUES=<?x.dest-city(x)-{marseille, lyons,

paris}, …>