godis
Download
Skip this Video
Download Presentation
GoDiS

Loading in 2 Seconds...

play fullscreen
1 / 60

GoDiS - PowerPoint PPT Presentation


  • 135 Views
  • Uploaded on

GoDiS. AI-course, Chalmers April 22, 2002 Staffan Larsson. this lecture. introduction to GoDiS information state moves, plans, actions accommodation optimistic grounding and acceptance information-oriented vs. action oriented dialogue command dialogue & menus

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' GoDiS' - carlow


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
godis

GoDiS

AI-course, Chalmers

April 22, 2002

Staffan Larsson

this lecture
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
godis features
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
slide4

GoDiS & TrindiKit

domain-specific

GoDiS system

domain & language

resources

QUD-based dialogue

theory (IS, rules, ...)

generic GoDiS system

TrindiKit

information state

approach

slide5

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

basic godis infostate type
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

sample godis information state
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}

activity based moves in godis
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
sample update rule
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:

dialogue plans
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
dialogue plan constructs
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)
actions
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)
questions
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?”
typical human computer dialog
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

dialogue plans for information seeking dialogue
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
dialogue plan formal representation
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))
typical human human dialogue
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

...

accommodation
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
question accommodation
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
update rule for question accommodation
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:

question accommodation1
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 )

task accommodation
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
update rule for task accommodation
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:

task accommodation1
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

question and task accommodation in information seeking dialogue
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?

an optimistic approach to grounding
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)
update rule for optimistic grounding
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:

slide28

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 )

optimistic approach to acceptance
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
optimistic acceptance
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 )

godis features1
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)
information vs action oriented dialogue
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)
information oriented dialogue
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
action oriented dialogue
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
godis aod extended infostate type
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:…

menu based natural command dialogue d homme
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.
menus vs dialogue drawbacks of menus
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
menu vs dialogue advantages of flexible dialogue
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
menu components
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”
sample menu from a nokia 3210 mobile phone
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
converting menus to plans cont d
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
the menu again
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
corresponding plan
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))))

another plan change ringtone
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);

example 1 standard menu navigation
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.

example 2 question accommodation
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.

example 3 task accommodation
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.

example 4 task clarification
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

example 5 video task and question accommodation
Example 5 (video): task and question accommodation

U: record from 19:30 to 20:00 today

  • accommodate task: add program
  • accommodate ”what starting time?”
  • accommodate ”what end time?”
  • accommodate ”what day?”

S: What channel?

U: Seven

S: OK, I will record channel 7 from 19:30 to 20:00 today.

example 6 doing several things at once
Example 6: doing several things at once

U: Search the phonebook for Jim

S: The number is 031 997321

U: Assign ringtone “Attraction”

    • name(jim) is already a shared proposition

S: The ringtone for Jim is now Attraction. Do you want to make a call?

U: No

  • Note: proposition name(jim) is used by both plans
instructional dialogue
Instructional dialogue
  • user carries out actions
  • goals of this research:
    • explore the relation between monologue and dialogue in instructional discourse
    • investigate possibilities of using domain task plans to generate dialogue plans providing various levels of interactivity
    • adapt GoDiS to handle instructional dialogue (and monologue)
  • NB. We are not dealing with educational (a.k.a. instructional) dialogue
  • TrindiBook chapter 9; Larsson & Zaenen (2000) SigDial paper
example from a xerox manual
Example from a Xerox manual
  • Reinstalling the print head
  • Caution: make sure that the green carriage lock lever is STILL moved all the way forward before you reinstall the print head
  • 1. Line up the hole in the print head with the green post on the printer carriage
  • Lower the print head down gently into position
  • 2. Gently push the green carriage lock lever up until it snaps into place
  • This secures the print head
  • 3. Close the tops cover and re-attach the scanner
  • 4. Press and release the yellow LED button
  • The printer will prepare the cartridge for printing
  • Note: if the carriage does not move from the center position after you press the carriage change button, remove and reinstall the print head
dialogue mode
dialogue mode
  • 8 moves (6 standard GoDiS moves, + Instruct and Confirm)
  • Confirmations are integrated by assuming that the current top-most action of the shared.actions has been performed
  • rule integrateUsrConfirm (slightly simplified)

in(SHARED.LU.MOVES, confirm)

val(SHARED.ACTIONS, A)

pre:

pop(SHARED.ACTIONS)

add(SHARED.COM, done(A))

eff:

sample information state
Sample information state

AGENDA = { findout(?moved(carriage)) }

if_then( not moved( carriage ),

[ remove(print_head),

reinstall(print_head) ] )

PRIVATE =

PLAN =

BEL = { }

TMP = (same structure as SHARED)

moved_forward(carriage_lock)

done(secure(print_head))

done(close(top_cover))

done(reattach(scanner))

COM =

SHARED =

ACTIONS= < press_and_release(yellow_button) >

QUD = < >

LU.MOVES { instruct(sys, press_and_release(yellow_button)}

example from a xerox manual repeated
Example from a Xerox manual (repeated)
  • Reinstalling the print head
  • Caution: make sure that the green carriage lock lever is STILL moved all the way forward before you reinstall the print head
  • 1. Line up the hole in the print head with the green post on the printer carriage
  • Lower the print head down gently into position
  • 2. Gently push the green carriage lock lever up until it snaps into place
  • This secures the print head
  • 3. Close the tops cover and re-attach the scanner
  • 4. Press and release the yellow LED button
  • The printer will prepare the cartridge for printing
  • Note: if the carriage does not move from the center position after you press the carriage change button, remove and reinstall the print head
dialogue behavior with minimal interactivity
dialogue behavior with minimal interactivity
  • yes/no questions
  • confirm (”ok”)
  • requestRepeat (”what?”)
  • grounding and avoidance of irrelevant information
  • example:
      • S: Press and release the yellow button
      • U: ok
      • S: Has the carriage moved from the center position?
      • U: yes
      • S: the print head is now installed
      • U: what?
      • S: the print head is now installed
increased interactivity
increased interactivity
  • skipping subtask instructions
    • S: Put the print head in place
    • U: Ok, done, what now?
    • S: Close the top cover
  • requesting subtask instructions; popping out of subdialogue
    • S: Put the print head in place
    • U: how?
    • S: Line up the hole in the print head with the green post on the printer carriage
    • U: done, I now remember the rest, the print head is secured
conclusions
conclusions
  • GoDiS is based on QUD and dialogue plans
    • QUD has independent motivation in dialogue semantics & ellipsis resolution (Ginzburg)
    • no planning needed in many domains; use ready-made plans but allow user initiative
  • QUD accommodation
    • theoretically motivated
    • enables mixed initiative
  • Demonstrates reusability
    • Originally implemented for information-oriented dialogue
    • but straightforward to extend to handle simple action-oriented dialogue
  • Demonstrate exploratory use of TrindiKit
    • explore relation between instructional text and dialogue