170 likes | 366 Views
Negotiative dialogue. some definitions and ideas. 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
E N D
Negotiative dialogue some definitions and ideas
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
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]
Optimistic approach to acceptance • DPs assume their utterances are accepted (and integrated into SHARED) • If A asks a question with content Q, A will put 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
Negotiativity • Negotiation is a type of problem-solving (cf. Di Eugenio et. al., Coconut) • Negotiation: DPs discuss several alternative solutions before choosing one of them • Negotiation does not imply conflicting goals • perhaps not 100% correspondence to everyday use of the word “negotiation”, but useful to keep collaborativity as a separate dimension from negotiation • Both AOD and IOD can be negotiative • in a flight information service, the user does not become obliged to fly anywhere; so it’s IOD • but several different flights may be discussed
Negotiation tasks • Some factors influencing negotiation • distribution of information between DPs • whether DPs must commit jointly (e.g. Coconut) or one DP can make the comittment (e.g. flight booking) • We’re initially trying to model negotiation in flight booking • sample dialouge • U: flights to paris on september 13 please • S: there is one flight at 07:45 and one at 12:00 • U: what airline is the 12:00 one • S: the 12:00 flight is an SAS flight • U: I’ll take the 12:00 flight please • Sys provides alternatives, User makes the choice • Sys knows timetable, User knows when he wants to travel etc.
Degrees of negotiativity • non-negotiative dialogue: only one alternative is discussed • semi-negotiative dialogue: a new alternative can be introduced by altering parameters of the previous alternative, but previous alternatives are not retained • negotiative dialogue: several alternatives can be introduced, and old alternatives are retained and can be returned to
Semi-negotiative dialogue • Does not require keeping track of several alternatives • Answers must be revisable; this can be done using reraising of answered questions • Correction of optimistic assumption of acceptance not necessarliy distinguished from revision • Example: Swedish SJ system (Philips): ”Do you want an earlier or later train?”
Issues Under Negotiation i negotiative dialogue • IUN is a 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 • Needs a new IS field: SHARED.IUN of type assocset(question,set(answer))
Alternatives in negotiation • Alternatives are alternate answers to an IUN • a proposal is the introduction of a new possible answer to IUN • An IUN is resolved when an answer to it is given, i.e. when an alternative is accepted • Alternatives and information about them is optimistically assumed to be accepted • Alternatives are needed whenever database search can return more than one result
General and specific information • General information concerns all alternatives, and is collected in an initial information-seeking dialogue (e.g. flights to paris) • e.g. x.dest(x,Paris) • Specific information concerns specific alternatives (e.g. flight f345 leaves at 10:45) • Specific info usually results from a database search whose input is general info; does this motivate separate fields in IS?
Example • IUN is lx.sel_flight(x) (“which is the chosen flight”?) • A: flight to paris, december 13 • answer(x.dest(x,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))
B: OK, there’s one flight leaving at 07:45 and one at 12:00 AGENDA = { findout(?x.sel_flight(x)) } PLAN = findout((?x. ccn(x)) book_ticket PRIVATE = BEL = {flight(f1), dep_time(f1,0745), ... } TMP = (same structure as SHARED) IUN = < ?x.sel_flight(x)-{f1, f2 }> SHARED = dep_time(f1,0745), dep_time(f2,1200) x.dest(x, paris), ... COM = QUD = <> LM = {propose(f1), propose(f2), answer(dep_time(f1,07:40),...}
Interpretation of NPs • Interpretation of ”the 7:45 one” uses unification and coercion • all answer-contents which match propositions in SHARED.COM is unifed with this info; e.g. dep_time(X,07:45) is unified with dep_time(f1,07:45) • the rest is added, e.g. sel_flight(X) with X=f1
Database search • Consulting DB with a set of (general) facts and a question (e.g. X^flight(X)) gives a list of alternative answers to the question AND info related to each of these alternatives • Example • FLIGHT DEP_TIME COMPANY • f1 07:45 KLM • f2 12:00 SAS • After doing the inital DB search, store results in PRIVATE.BEL, give some information about each alternative, e.g. flight departure time
Plans • some info must be obtained from user, and some is found in DB; how flexible is this division? • a simple solution • departure date, destination, origin and class is obtained from user • (exact) departure times, company etc is always found in DB • departure times are always adressed when giving proposals; other info can be requested by user • flight booking • findout(X^dest_city(_,X)), ... • consultDB • propose • adress(X^dep_time(_,X)) • findout(X^sel_flight(X)) • a better solution: implicit negotiation of dialogue strategy (Lewin)
Revising general information • Problem when general information is revised • solution: see it as defaults; if it is altered, turn it into specific info for all current alternatives which do not contradict the default