Towards LinguisticallyMotivated Universal Basic Conversation Move Classes for Conversation Programmi

1
Towards Linguistically-Motivated Universal Basic
Conversation Move Classes for Conversation
Programming

• Norihiro Ogata
• Faculty of Language and Culture
• Osaka University
• Japan

2
Outline

• Linguistic Approaches
• Speech API
• Agent Communication Language
• UCMC as structured classes of specifications of
  Dialogue Acts
• Conversation Programming as specifications of
  strategies, effects, and purpose.
• Future Works

3
Linguistic Approaches Classifications of Moves
from multiple viewpoints

• Conversational Analysis Repairs, Repetitions,
  Openings, (Turn-Taking Moves), etc. ? based on
  functions, roles and forms
• Computational Linguistics Dialogue acts (Game
  Moves, VERMOBIL, etc.) ? based on functions,
  roles, speech acts, relevance of (domain)
  contexts or tasks, forms, etc.

4
Kowtko et al.s Game Moves
5
The Japanese DTAG (DRI)

• Conventional OPEN, CLOSE
• Initiate REQUEST, SUGGEST, PERSUADE, PROPOSE,
  CONFIRM, YES-NO Q, WH-Q, PROMISE, DEMAND, INFORM,
  OTHER ASSERTION, ...
• Respond POSITIVE, NEGATIVE, ANSWER, HOLD, ...
• Follow-up UNDERSTANDING

6
Dialogue Acts of VERBMOBIL-2
7
The DAMSL (Dialogue Act Markup in Several Layers)
Annotation Scheme
8
Their main purposes are (semantic or functional)
classification for analyzing and tagging
corpora, and translation.Rather, formal
specifications of dialogue moves and contexts is
needed for conversation programming.
9
Some of the available tools for conversation
programming are ---

• Speech APIs - e.g., The Java Speech API
• Agent Communication Languages (ACL)

10
Towards Conversation Programming Multilingual
Speech API

• The Java Speech API which is connected with
  Speech Grammar and Speech Markup Language (SML) ?
  Multilingual Speech Programming Tool based on
  Object-Oriented Analyses of Speech

11
Towards Conversation Programming Multilingual
Speech API

• But, it is not so easy to construct conversation
  systems using Speech API, because of gap between
  speech and dialogue acts
• e.g., Speech API only commits only on vocal and
  lexical properties of utterances.

12
Agent Communication Language

• ACL provides agents communication protocol.
• But, too coarse to handle real conversation,
  since it includes non-speech-act-based dialogue
  acts, and ACL is based on speech acts and
  propositional attitudes.
• e.g., KQML provides a set of predicates tell,
  subscribe, evaluate, next, recruiting, etc.which
  are too coarse to treat dialogue acts.

13
Classes of Dialogue Moves as Intermediate Level
between Speech API and ACL

• not a simple mapping between Speech APIs and ACLs
• must include a turn-exchange model and
  multilingual properties
• needs formal analysis of classes of
  conversational moves and contexts (by object
  modeling (UML))
• proposal CONTEXT, TURN MODEL and Univesal
  Conversation Move Classes (UCMC)

14
class CONTEXT

• arrayAGENT CONVERSANTS
• Boolean SELF(AGENT) the agent itself
• Boolean OTHER(AGENT) the non-self agents
  addressee
• pointer to AGENT SPEAKER the turn-taken
  conversant
• pointer to AGENT HEARER all the conversants
  paying attention to the conversation
• pointer to AGENT ADDRESSEE the conversant who
  the speaker is talking to
• string FORM the utterance ...

15
Universal Conversation Move Classes (UCMC)

• operational semantics, i.e., basically classes of
  update functions of contexts MCONTEXT ?
  pow(CONTEXT) define propertys value, set the
  values certainty Doubtful, Unsure, Sure, ...,
  reset it, or redefine it

16
Universal Conversation Move Classes (UCMC)

• have turn constraint properties based on TURN
  MODEL canOverlap, INTRUDABLE, PROTECTED, etc.
• have multilingual utterance specification

17
Interaction of CONTEXT, MOVE, and AGENT
MOVE
CONTEXT
prevCONTEXT()
get(PROPERTY) set(PROPERTY) ...
say(FORM)
nextCONTEXT()
CONTEXT
hear(InputStream)
AGENT
addCONVERSANT(AGENT)
recognizer
synthesizer
ACL , KB
array of CONTEXT
Speech API
18
Speaker (Turn-Taken Conversant)
AGENT
CONTEXT
addCONVERSANT
SPEAKER HEARER ADDRESSEE
CONVERSANTS
setSPEAKER
setHEARER
19
Hearer (All Conversants)
AGENT
CONTEXT
addCONVERSANT
SPEAKER HEARER ADDRESSEE
CONVERSANTS
setHEARER
20
Addressee(Who the speaker is talking to)
AGENT
CONTEXT
addCONVERSANT
SPEAKER HEARER ADDRESSEE
CONVERSANTS
setHEARER
setAddressee
21
Turns as Concurrent Processes MODEL
(Back-channelling)
Speaker synthesizer recognizer
Hearer recognizer synthesizer
idling
uttering
canOverlap
notIntrudable
uttering
protected
idling
uttering
(monitoring)
22
Turn Taking
Speaker synthesizer recognizer
Hearer recognizer synthesizer
idling
uttering
canOverlap
intrudable
uttering
not protected
idling
interrupted
TURN
(monitoring)
23
Turn Transferring
Speaker synthesizer recognizer
Hearer recognizer synthesizer
idling
uttering
uttering
idling
TURN
(monitoring)
24
Turn-Giving-Up
Speaker synthesizer recognizer
Hearer recognizer synthesizer
idling
uttering
(PAUSE)
canOverlap intrudable
uttering
idling
TURN
(monitoring)
25
This TURN MODEL can also handle the other types
of (sub)dialogue

• If SELF(SPEAKER) and OTHER(ADRESSEE) then, the
  move can be an ...
• OTHER-INTERRUPTION other-repair, etc.
• OTHER-OVERLAPPING back-channelling, repetition
  as a back-channelling, etc.

26
This TURN MODEL can also handle the other types
of (sub)dialogue

• If SELF(SPEAKER) and SELF(ADRESSEE) then, the
  move can be a ...
• SELF-INTERRUPTION self-repair, self-correction
  in the middle, etc.
• SELF-OVERLAPPING stutter oh!, you know,
  no, sorry etc. in the middle, etc.

27
Operational Semantics isnt neither the Strategy,
the Purpose, nor the Effect

• repetitions can be used for multiple purposes,
  strategies or intention (joking strategy (Norrick
  1994), readback in air traffic control (Cushing
  1994), confirmation of humanness (Brewer 1994),
  etc.)

28
Operational Semantics isnt neither the Strategy,
the Purpose, nor the Effect

• But, most repetitions can be classified into some
  classes in terms of how to change CONTEXT and
  their forms (operational semantics viewpoint)
• Therefore, repetitions are specified in terms of
  their operational semantics in UCMC

29
Conversation Programming as Specifications of
the Effect and the Purpose

• e.g., If the task needs politeness and accuracy,
  then use a kind of repetition and set
  intrudability high.

30
Conversation Programming as a specification of
the Strategy

• In invitation/proposal conversations in Japanese,
  a strong persuasion isnt prefered,
• on the other hand, in English, a persuasion by
  enumeration of profitable points is preferred.
  (Szatrowski 1992)
• This is handled by the adjustment programming of
  initiations of sudialogues on intention sharing.

31
A very rough example of an invitation strategy
l is an array of profits of x for (i 0i lt n
i) s1subdialogInit of Intention li
do(s1) //say s, transfer the turn
unless REFUSED s2confirmation do(s2)
unless REFUSED exit
32
Examples of UCMC
33
class Move

• description the most abstract move class
  conversation
• operational semantics form or update a context
  instance
• properties PROTECTED, canOverlap, INTRUDABLE are
  undefined
• formundefined
• superclass implementation dependent (e.g.,
  Speech APIs classes, ACLs classes) subclasses
  all UCMCs

34
class metaMove

• description the most abstract move class
  conversation
• operational semantics introduce a new context
  instance, define SELF, CONVERSANTS, OTHER
• properties PROPOSITION0
• formundefined
• superclass predialogInit
• subclasses greetingInit, summonsing, etc.

35
class speakTo

• description the first move of a total
  conversation
• operational semantics introduce a new context
  instance, define OTHER, CONVERSANTS, SELF
• properties stronglyProtected
• form Excuse me Chotto ii desu ka, Suimasen
• superclass predialogInit
• subclasses greetingInit, ummonsing, etc.

36
class confirmationalRepetition

• description the move replicates some previous
  move in confirmation tone
• operational semantics Doubtful(prevCONTEXT.form)
  
• properties(Protected)
• form prevCONTEXT.form confirmation tone
• superclass Confirmation
• subclasses

37
class repairRepetition

• description the move replicates some previous
  move in repair tone
• operational semantics Unsure(prevCONTEXT.form)
• properties(Protected)
• form prevCONTEXT.form repair tone
• superclass Repair
• subclasses

38
class talkIntoJoining

• description the move talking into joining the
  conversants
• operational semantics introduce a new
  conversant, update CONVERSANTS
• properties intrudable, canOverlap
• form Be quiet, Listen, Attention Chotto kiite?,
  Chotto sizukani.
• superclass speakTo
• subclasses

39
Summary

• A fragment of Universal Conversation Move Classes
  based on class CONTEXT, TURN MODEL, and
  specifications of operational semantics of
  dialogue acts
• They intervenes between (partially includes)
  Speech APIs and ACLs
• A framework of Conversation Programming as
  specifications of effects, purposes, strategies
  of conversations

40
Future Works and Problems

• More detailed specifications by UML
• Implementation by the Java Speech API and Javas
  agent programming
• (However) now the support of the Java Speech API
  isnt so sufficient, and the Java Speech Grammar
  Format doesnt handle intonation specifications
  (The Java Speech Markup Language supports
  prosodic specifications).
• Investigation of the relevance to formal
  semantics of conversation ? verification of
  conversation programming and processes of
  conversations