goteborg university dialogue systems lab wp2: godis, dialogue plans and ontologies edinburgh talk...

Goteborg University Dialogue Systems Lab

WP2: GoDiS, dialogue plans and ontologies

Edinburgh TALK meeting7/10 2004


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


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


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)


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


• 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


• 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


• Not included in GoDiS ontologies:– part-whole relations– intentional structure:

• satisfaction-precedes• intentional dominance (decomposition);

instead in dialogue plans


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)


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)


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


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


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”


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)


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)


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


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


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?


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


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)


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?


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


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


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

goteborg university dialogue systems lab wp2: godis, dialogue plans and ontologies edinburgh talk...

Documents

godis slide

dialogue plans

dialogue phenomena

godis summary slide

stacksetquestion slide

stackset action lu

stackset action agenda

sequential structure