Abstract task specifications for conversation policies

Abstract

Under some views, a crucial function for conversation policies is to "constrain the messages that appear on the wire,'' for there can be a many-to-many mapping between an agent's intention and the message primitive used to express that intention. In this paper, we argue that the way to constrain messages is to constrain intentions. We propose a pragmatic approach to doing this through an abstract task specification or model. Abstract task specifications are based on a simple state-space representation for problem formulation, and this representation can be used to delimit the agents' task intentions and discourse intentions. This analysis supports a flexible and pragmatic way of handling "unexpected'' messages by reference to the abstract task specification. We see an abstract task specification as one component of a publicly posted conversation policy. A simple search-assistant agent was implemented within a BDI architecture to illustrate application of these ideas.

In-home access to multimedia content

“…one without recommendation, at first glance the problem could be solved optimally by building the solution query in the smallest number of steps. 4 In other words, the quality of the conversational assistant could be measured simply by counting the number of questions required to reach the solution query. However, this utility function is based on the assumption that user satisfaction is solely dependent on the length of the dialogue.…”

“…This problem can actually be divided into two different parts: at a higher level we have a dialogue management issue, and at a lower level we have to decide which attribute to select [4]. We will now proceed to explain both problems in greater detail.…”

Multi-Agent System Interaction Protocols in a Dynamically Changing Environment

“…Our solution is to model these kinds of interactions that can guide, interrupt, or redirect existing conversations by representing them as another, parallel modelling layer above that of the existing conversation layer. This idea was suggested in [2] for specific types of conversation, but we have generalised the notion and incorporated it into a Petri Net representation. Thus a conversation is a combination of protocols being instantiated and manipulated by a particular policy.…”

An agent-based infrastructure for enterprise integration

“…Extended FSM models, which, like COOL, focus more on expressivity than adherence to a model include Kuwabara et al [22,21], who add inheritance to conversations; Wagner et al [46]; and Elio and Haddadi [14], who defines a multilevel state machine, or ATM. A few others have chosen to stay within the bounds of a DFA, such as Chauhan [7], who uses COOL as the basis for her multi-agent development system, 1 Nodine and Unruh [34,35], who use conversation specifications to enforce correct conversational behavior, and Pitt and Mamdani [40], who use DFAs to specify protocols for BDI agents.…”

“…In either case, the agent is given a new FQAN, which is derived from the Given Name of the name submitted. For example, if an agent registers orianus.local with freckles.cs [1].umbc.ans (alternatively, freckles.cs [1].umbc.http://jackal.cs.umbc.edu/ans), it may receive the FQAN orianus [14].cs [1].umbc [23].ans.…”