goteborg university dialogue systems lab wp2: godis, dialogue plans and ontologies edinburgh talk...
Post on 18-Dec-2015
217 views
TRANSCRIPT
Goteborg University Dialogue Systems Lab
WP2: GoDiS, dialogue plans and ontologies
Edinburgh TALK meeting7/10 2004
Goteborg University Dialogue Systems Lab
Some dialogue phenomena discussed by Milward & Beveridge (2004, Catalog)
• Hyponym clarifications / underspecification– too unspecific information; clarification required
• Hypernyms / overspecification– over-specific information; system should adapt
• Sequential structure – keeping track of shifting topics– deviations from default topic order
• In Milward’s system, the above phenomena are dealt with using ontologies
• This presentation shows how they are dealt with by issue-based dialogue management in GoDiS
Goteborg University Dialogue Systems Lab
Overview
• GoDiS infostate• Ontology in GoDiS
– dealing with clarification dialogues for hypernyms and hyponyms
• Menu-based dialogue i GoDiS– converting menus to dialogue plans– dependent accommodation– dealing with sequential dialogue structure &
focus of attention in GoDiS• Summary
Goteborg University Dialogue Systems Lab
GoDiS information state
PRIVATE :PLAN : stackset( Action )
AGENDA : stack( Action )
SHARED :
BEL : set( Prop )
TMP : (same type as SHARED)
COM : set( Prop )
QUD : stackset( Question )
ACTIONS : stackset( Action )
LU:…
ISSUES: stackset(Question)
Goteborg University Dialogue Systems Lab
Ontology in GoDiS: semantic sorts
• semsort/2: semantic sorts of individuals• semsort(Ind, Pred)
– Example: semsort(N, channel) if 0<N<100– Pred(Ind) is a valid proposition– Ind resolves ?x.Pred(x)
• 55 resolves ?x.channel(x) to channel(55)
• VCR semsort-excerpt– play_status: playing, stopped– program: 0 < N < 9, N is an integer– channel: 0 < N < 100, N is an integer
Goteborg University Dialogue Systems Lab
• isa/2: relations between extensions of predicates
• isa(Pred1, Pred2): if Pred1(X) then Pred2(X)
• Examples:– isa(channel, number)– isa(channel_to_store, channel)
• It also follows that Pred2(a) resolves ?x.Pred1(x)– channel(55) resolves ?x.channel_to_store(x) to channel_to_store(55)
Ontology in GoDiS: isa-hierarchy
Goteborg University Dialogue Systems Lab
• VCR isa-hierarchy excerpt:– number
• channel– channel_to_store– new_channel
• date• time
– start_time_to_store– stop_time_to_store– new_clock
• program– program_to_delete
Goteborg University Dialogue Systems Lab
• Not included in GoDiS ontologies:– part-whole relations– intentional structure:
• satisfaction-precedes• intentional dominance (decomposition);
instead in dialogue plans
Goteborg University Dialogue Systems Lab
Dialogue phenomenon:Clarification Dialogues for hypernyms
• Providing less specific information than requested• A slightly different example than in Milward’s paper
– here, the problem is to figure out which question the user is answering (before it has been asked – question accommodation)
• Hypernym answers (less specific)– S: Adding a program. What channel do you want?– U: channel five, six thirty– S: OK, channel five. Do you mean from six thirty or until six thirty?
• Here ”six thirty” is interpreted as time(6:30), but – isa(start_time, time)– isa(end_time, time)
• So time(6:30) could be an answer to either – ?x.start-time(x)– ?x.end-time(x)
Goteborg University Dialogue Systems Lab
Dialogue phenomenon: Hyponym answers
• any answer which is more specific than needed will resolve the question
• In ontology:– semsort(leukemia, cancer)– isa(cancer, chronic_disease)
• leukemia resolves ?x.chronic_disease(x)• also resolves ?x.cancer(x)• GoDiS never asks a question which is
already resolved; all questions on the plan are first checked against available information (shared committments)
Goteborg University Dialogue Systems Lab
Sequential Structure
• Milward & Beveridge: if a subtopic is introduced, the system should continue on the subtopic
• In GoDiS, this is handled by question stack structure and question accommodation
• This results in GoDiS obeying the sequential structure constraints described by Milward & Beveridge– at least for the examples in the paper
• In effect, the action stack encodes the path to the current node
• plans are loaded depending on topmost action
Goteborg University Dialogue Systems Lab
GoDiS Dialogue plans
• so far, only pre-scripted• can be derived from e.g. analysis
WOZ corpus, existing menu system, existing domain task plans
• dialogue management is domain-independent
Goteborg University Dialogue Systems Lab
Menu-based dialogue: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”
Goteborg University Dialogue Systems Lab
Converting menus to plans
Menu Planmulti-choice list A1, A2, ..., An
findout({?A1, ?A2,...,?An })
tick-box +/-P findout(?P)
dialogue windowp=___
findout(?x.p(x))
pop-up message M
confirm(A)
Goteborg University Dialogue Systems Lab
Menu-style dialogue plans
• Dialogue plans encode– action domination
• dominates( Action1, Action2 )• inferred from plan/2 if possible
– default ordering of actions (not strict)• plan( Action, Plan )
• Not currently included:– satisfaction-precedes (default ordering
can always be modified by accommodation)
• plan(Action, PlanConstruct)
Goteborg University Dialogue Systems Lab
Action hyponyms
• Action hierarchy– encoded in plans– A0
• A1– A11– A12
• A2
• Skipping down to subtasks– ”Over-specific” requests handled using dominates/2– Requesting a more specific action (e.g. A12) than
those asked about (say, A1 and A2) will lead to A12 being loaded
– the issue {?action(A1),?action(A2)} is resolved by A12 since A1 dominates A12
Goteborg University Dialogue Systems Lab
Allowing flexible dialogue structure• transitive action accommodation (using simple ”plan
recognition”)– user provides information A not relevant to any current
action– find a dialogue plan P (in the domain knowledge) such that
A is relevant to some issue Q in P• plan(Action,P) where P=[findout(Q),...], A relevant to Q
– accommodate by pushing the action (or issue) associated with P on ACTIONS
• SHARED/ACTIONS = <Action, ...>– load P into the PLAN field– accommodate Q to ISSUES and QUD and integrate A, as in
simple case– system will now proceed with PLAN– when PLAN is finished, Action will be popped and the
previous action will be resumed
Goteborg University Dialogue Systems Lab
Menu-based Action-Oriented Dialogue
S: Welcome to the VCR manager!U: Channel one today
[ here, the action ”add_program” is accommodated]S: Right, I assume you want to add a program. S: Let’s see. Okay. Channel one. Today. S: What time do you want to start recording?U: Set the clock to two forty five
[ a new action is requested and pushed on stack ]S: Okay, set the clock. Two forty five, is that correct?U: Yes.S: Okay. The clock was set.
[here, the action stack is popped and system returns to previous topic]
S: Returning to timer recording. So, what time do you want to start recording?
Goteborg University Dialogue Systems Lab
Cancer domain plans
• Not really a menu-like system– system does not ask about what the user
wants to do next (selecting from a list of alternatives)
– instead, a hierarchical plan where all actions need to be executed
• However, several GoDiS mechanisms are useful
• In GoDiS, there is not one monolothic plan, instead several interconnected single-layered plans
Goteborg University Dialogue Systems Lab
plan(referral_advice, [ exec diagnostic_signs, exec referral_decision ])
plan(diagnostic_signs, [ exec patient_details, exec clinical_details, findout( ?x.family_history(x) ] )
plan( patient_details, [ findout( ?x.age_state(x)) , findout( ?x.sex_state(x)) ] )
plan( clinical_details, [ findout( ?bilateral_nipple_discharge ), findout( ?nipple_discharge) ] )
isa( bilateral_nipple_discharge, nipple_discharge )so bilateral_nipple_discharge resolves ?nipple_discharge
referraladvice
diagnosticsigns
referraldecision
patientdetails
clinicaldetails
?x.age-state(x)
diagnosticsigns
?x.sex-state(x)
patientdetails
clinicaldetails
?bilateral-n.d.
?nipple-discharge
?x.family-history(x)
Goteborg University Dialogue Systems Lab
Dialogue phenomenon:Sequential Structure
– ACTIONS = < collect_patient_details, collect_diagnostic_signs, referral_advice >
– PLAN = < findout(?x.sex-state(x)), findout(?x.age-state(x))>• S: Let’s get patient details. What is the patient’s sex
– QUD = < ?x.sex-state(x)>• U: Female with some nipple discharge
– interpreted as [answer(female), answer(nipple_discharge)]– answer(female) resolves ?x.patient_sex(x)– nipple_discharge is relevant to ?nipple_discharge
• plan(collect_clinical_details, [findout(?bilateral_discharge), findout(?nipple_discharge)])
– so collect_clinical_details is now accommodated– ACTIONS = < collect_clinical_details, collect_patient_details, ... >– contents of PLAN field updated to correspond to topmost ACTION– PLAN = [findout(?bilateral_discharge), findout(?nipple_discharge)]– ?nipple_discharge is already resolved– proceed to next plan item: findout(?bilateral_discharge)
• S: Alright, let’s do clinical details. Does the patient have bilateral nipple discharge?
Goteborg University Dialogue Systems Lab
• S: What is the patient’s sex• U: Female with some nipple discharge
– ACTIONS = < collect_clinical_details, collect_patient_details, ... >– PLAN = [findout(?bilateral_discharge), findout(?nipple_discharge)]
• S: Alright, let’s do clinical details. Does the patient have bilateral nipple discharge?
• U: no– current PLAN finished, topmost action done, so pop ACTIONS– ACTIONS = < collect_patient_details, ... >– reload plan for dealing with topmost action– PLAN = < findout(?x.sex-state(x)), findout(?x.age-state(x))>– but ?x.sex-state(x)) already resolved, so remove– proceed to next plan item– plus: signal popping the ACTIONS stack
• S: Returning to patient details. What’s the patient’s age?
Goteborg University Dialogue Systems Lab
Summary
• So, while GoDiS plans are basically lists...• the whole set of plans can be hiearchically
ordered• question accommodation is used not only to
handle cases where the user provides additional information matching the current plan...
• ...but generally serves to adjust the question stack in various ways so that sequential constraints are obeyed, at least in the examples in Milward & Beveridge paper
• GoDiS has a rudimentary ontology, to deal with (some) cases of hyper- and hyponyms
Goteborg University Dialogue Systems Lab
However...
• GoDiS does not use is-a hierarchy for focus management
• instead, relies on the fact that the associated questions appear in the same subplan
• If the isa-link stretches over two separate subplans, the elaboration question would not be raised immediately