1. Scope
This document forms part of the FIPA 1998 standard. It provides a specification dealing with technologies that support design or implementation of the human-agent interaction part of an agent system. This part of FIPA 98 defines basic functionality that can be utilized by an agent-based application which needs to interact with human users. The purpose of this document is to standardize the basic functionality and interface of agents that are able to (1) manage dialogs with users at a higher level of operations or to (2) support personalization of both human-agent interaction and other agent behavior by constructing and maintaining user models. User models may be user profiles, i.e. stores of explicitly given information about the user, or may be acquired by learning from observations of user behavior.
The specification defines a reference model, identifying necessary agent functionalities, messages and actions which define each of these functionalities, and objects that are used as action parameters. It builds upon FIPA 97 specifications and other parts of FIPA 98 specifications.
2. Normative reference(s)
FIPA 97 – International standard for the inter-operation of software agents – Part 1: Agent Management.
FIPA 97 – International standard for the inter-operation of software agents – Part 2: Agent Communication Language.
FIPA 97 – International standard for the inter-operation of software agents – Part 3: Agent/Software Integration.
P3P – Platform for Privacy Preferences (P3P) Syntax Specification. W3C Working Draft 2-July-1998. http://www.w3.org/TR/WD-P3P10-syntax
vCard – Internet Mail Consortium, "vCard – The Electronic Business Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt
3. Terms and definitions
For the purposes of this specification, the following terms and definitions apply:
Action
A basic construct which represents some activity which an agent may perform. A special class of actions is the communicative acts.
Agent
An Agent is the fundamental actor in a domain. It combines one or more service capabilities into a unified and integrated execution model which can include access to external software, human users and communication facilities.
Agent cloning
The process by which an agent creates a copy of itself on an agent platform.
Agent code
The set of instructions used by an agent.
Agent Communication Language (ACL)
A language with precisely defined syntax, semantics and pragmatics that is the basis of communication between independently designed and developed software agents. ACL is the primary subject of this part of the FIPA specification.
Agent Communication Channel (ACC)
The Agent Communication Channel is an agent which uses information provided by the Agent Management System to route messages between agents within the platform and to agents resident on other platforms.
Agent data
Any data associated with an agent.
Agent invocation
The process by which an agent can create another instance of an agent on an agent platform.
Agent Management System (AMS)
The Agent Management System is an agent which manages the creation, deletion, suspension, resumption, authentication and migration of agents on the agent platform and provides a „white pages“ directory service for all agents resident on an agent platform. It stores the mapping between globally unique agent names (or GUID) and local transport addresses used by the platform.
Agent Platform (AP)
An Agent Platform provides an infrastructure in which agents can be deployed. An agent must be registered on a platform in order to interact with other agents on that platform or indeed other platforms. An AP consists of three capability sets ACC, AMS and default Directory Facilitator.
Agent Platform Security Manager (APSM)
An Agent Platform Security Manager is responsible for maintaining the agent platform security policy. The APSM is responsible for providing transport-level security and creating agent audit logs. The APSM negotiates the requested intra- and inter-domain security services of other APSM's in concert with the implemented distributed computing architectures, such as CORBA, COM, DCE, on behalf of an agent in its domain.
ARB Agent
An agent which provides the Agent Resource Broker (ARB) service. There must be at least one such an agent in each Agent Platform in order to allow the sharing of non-agent services.
Communicative Act (CA)
A special class of actions that correspond to the basic building blocks of dialogue between agents. A communicative act has a well-defined, declarative meaning independent of the content of any given act. CA's are modeled on speech act theory. Pragmatically, CA's are performed by an agent sending a message to another agent, using the message format described in FIPA 97, part 2.
Content
That part of a communicative act which represents the domain dependent component of the communication. Note that "the content of a message" does not refer to "everything within the message, including the delimiters", as it does in some languages, but rather specifically to the domain specific component. In the ACL semantic model, a content expression may be composed from propositions, actions, or other expressions.
Content Language
The content of a FIPA message refers to whatever the communicative act applies to. If, in general terms, the communicative act is considered as a sentence, the content is the grammatical object of the sentence. This content can be encoded in any language, the content language, denoted by the :language parameter of the communicative act.
Conversation
An ongoing sequence of communicative acts exchanged between two (or more) agents relating to some ongoing topic of discourse. A conversation may (perhaps implicitly) accumulate context which is used to determine the meaning of later messages in the conversation.
CORBA:
Common Object Request Broker Architecture, an established standard allowing object-oriented distributed systems to communicate through the remote invocation of object methods.
Directory Facilitator (DF)
The Directory facilitator is an agent which provides a „yellow pages“ directory service for the agents. It store descriptions of the agents and the services they offer.
Explicit & Implicit
An ontology is explicit when it is specified in declarative form as a set of axioms and definitions (e.g. as a set of Ontolingua statements) that an agent can refer to (e.g. by means of an OKBC interface). An ontology is implicit, when the assumptions on the meaning of its vocabulary are only implicitly embedded in some piece of software.
Feasibility Precondition (FP)
The conditions (i.e. one or more propositions) which need be true before an agent can (plan to) execute an action.
Illocutionary effect
See speech act theory.
Knowledge model
It is a specification of the set of primitives used by a certain class of representation languages. As such, a knowledge model can be considered as a meta-ontology. For instance, several ontology servers use an object oriented model of knowledge based on primitive notions like classes, frames, properties, constraints, axioms and functions. FIPA adopts for the specification of these notions the OKBC version 2.0.4 Knowledge Model, which is called FIPA-meta-ontology or FIPA knowledge model.
Knowledge Querying and Manipulation Language (KQML)
A de facto (but widely used) specification of a language for inter-agent communication. In practice, several implementations and variations exist.
Local Agent Platform
The Local Agent Platform is the AP to which an agent is attached and which represents an ultimate destination for messages directed to that agent.
Message
An individual unit of communication between two or more agents. A message corresponds to a communicative act, in the sense that a message encodes the communicative act for reliable transmission between agents. Note that communicative acts can be recursively composed, so while the outermost act is directly encoded by the message, taken as a whole a given message may represent multiple individual communicative acts.
Message content
See content.
Message transport service
The message transport service is an abstract service provided by the agent management platform to which the agent is (currently) attached. The message transport service provides for the reliable and timely delivery of messages to their destination agents, and also provides a mapping from agent logical names to physical transport addresses.
Meta-ontology
For allowing a FIPA agent to communicate through ACL messages aboutontologies, it is necessary to describe the concepts used to speak about anontology. This description is called the meta-ontology. It is an ontologyitself as it provides the ontology to refer to another ontology. Therefore,the meta-ontology should be powerful enough to deal with all potentiallyavailable ontologies and make explicit, at least informally, these concepts.
Mobile agent
An agent that is not reliant upon the agent platform where it began executing and can subsequently transport itself between agent platforms.
Mobility
The property or characteristic of an agent that allows it to travel between agent platforms.
Ontology
An ontology gives meanings to symbols and expressions within a given domain language. In order for a message from one agent to be properly understood by another, the agents must ascribe the same meaning to the constants used in the message. The ontology performs the function of mapping a given constant to some well-understood meaning. For a given domain, the ontology may be an explicit construct or implicitly encoded with the implementation of the agent.
Ontology Agent
An agent that provides the Ontology Service specified in this specification. The main objective of the Ontology Agent is to offer to FIPA agents a unified view of the services offered by the different ontology servers. Its second objective is to allow an ontology server to be known by FIPA agents. Moreover some ontology agents can provide the agents with services such as translation facilities. Like any other FIPA agent, the ontology agent has to be registered to the DF and to provide the DF with the published ontologies and available services.
Ontology Name
The ontologies referred to by the agents can be provided by different ontology servers. Consequently, these ontology names are constructed from: the OA name, and the ontology logical name (given by the ontology designer e.g. “car “).
Ontology Server
Provider of an Ontology Service, not necessarily in the FIPA domain, or FIPA-compliant. Examples of ontology servers already existing outside FIPA are: Ontolingua, XML/RDF ontology servers, ODL databases ontologies servers. Access to the services provided by these ontologies servers are based on various APIs such as the OKBC interface, the ODL interface or HTTP.
Ontology sharing problem
The problem of ensuring that two agents who wish to converse do, in fact, share a common ontology for the domain of discourse. Minimally, agents should be able to discover whether or not they share a mutual understanding of the domain constants.
Perlocutionary Effect
See speech act theory.
Personalization
An agent’s ability to take individual preferences and characteristics of users into account and adapt its behavior to these factors.
Proposition
A statement which can be either true or false. A closed proposition is one which contains no variables, other than those defined within the scope of a quantifier.
Protocol
A common pattern of conversations used to perform some generally useful task. The protocol is often used to facilitate a simplification of the computational machinery needed to support a given dialogue task between two agents. Throughout this document, we reserve protocol to refer to dialogue patterns between agents, and networking protocol to refer to underlying transport mechanisms such as TCP/IP.
Rational Effect (RE)
The rational effect of an action is a representation of the effect that an agent can expect to occur as a result of the action being performed. In particular, the rational effect of a communicative act is the perlocutionary effect an agent can expect the CA to have on a recipient agent.
Note that the recipient is not bound to ensure that the expected effect comes about; indeed it may be impossible for it to do so. Thus an agent may use its knowledge of the rational effect in order to plan an action, but it is not entitled to believe that the rational effect necessarily holds having performed the act.
Software Service
An instantiation of a connection to a software system.
Software System
A software entity which is not conformant to the FIPA Agent Management specification.
Speech Act
The notion of a speech act is derived from the linguistic analysis of human communication. It is based on the idea that with language the speaker not only makes statements, but also performs actions, e.g. a request or an assertion. In this context, a verb denoting a speech act, is called a performative, since saying it makes it so. See FIPA97, part 2 for more details.
Speech Act Theory
A theory of communications which is used as the basis for ACL. Speech act theory is derived from the linguistic analysis of human communication. It is based on the idea that with language the speaker not only makes statements, but also performs actions. A speech act can be put in a stylised form that begins "I hereby request …" or "I hereby declare …". In this form the verb is called the performative, since saying it makes it so. Verbs that cannot be put into this form are not speech acts, for example "I hereby solve this equation" does not actually solve the equation. [Austin 62, Searle 69].
In speech act theory, communicative acts are decomposed into locutionary, illocutionary and perlocutionary acts. Locutionary acts refers to the formulation of an utterance, illocutionary refers to a categorisation of the utterance from the speakers perspective (e.g. question, command, query, etc), and perlocutionary refers to the other intended effects on the hearer. In the case of the ACL, the perlocutionary effect refers to the updating of the agent's mental attitudes.
Stationary agent
An agent that executes only upon the agent platform where it begins executing and is reliant upon it.
TCP/IP
A networking protocol used to establish connections and transmit data between hosts
User Agent
An agent which interacts with a human user.
User Dialog Management Service
An agent service in order for FIPA agents to interact with human users; by converting ACL into media/formats which human users can understand and vice versa, managing the communication channel between agents and users, and identifying users interacting with agents.
User ID
An identifier for a real user.
User Model
A user model contains assumptions about user preferences, capabilities, skills, knowledge, etc, which may be acquired by inductive processing based on observations about the user. User models normally contain knowledge bases which are directly manipulated and administered.
User Personalization Service
An agent service that offers abilities to support personalization, e.g. by maintaining user profiles or forming complex user models by learning from observations of user behavior.
Wrapper Agent
An agent which provides the FIPA-WRAPPER service to an agent domain on the Internet.
4. Symbols (and abbreviated terms)
ACC: Agent Communication Channel
ACL: Agent Communication Language
AMS: Agent Management System
AP: Agent Platform
API: Application Programming Interface
APSM: Agent Platform Security Manager
ARB: Agent Resource Broker
CA: Communicative Act
CORBA: Common Object Request Broker Architecture
DB: Database
DCOM: Distributed COM
DF: Directory Facilitator
FIPA: Foundation for Intelligent Physical Agents
FP: Feasibility Precondition
GUID: Global Unique Identifier
HAP: Home Agent Platform
HTTP: Hypertext Transmission Protocol
IDL: Interface Definition Language
IIOP: Internet Inter-ORB Protocol
IPMT: Internal Platform Message Transport
IRE: Identifying Referring Expression
OMG: Object Management Group
ORB: Object Request Broker
P3P: Platform for Privacy Preferences Project
PICS: Platform for Internet Content Selection
RE: Rational Effect
RMI: Remote Method Invocation, an inter-process communication method embodied in Java
SL: Semantic Language
SMTP: Simple Mail Transfer Protocol
SQL: Structured Query Language
S/W: Software System
TCP / IP: Transmission Control Protocol / Internet Protocol
UDMA: User Dialogue Management Agent
UDMS: User Dialogue Management Service
UPA: User Personalization Agent
UPS: User Personalization Service
XML: eXtensible Markup Language
5. Overview
Human-agent interaction is a particularly important aspect that should be taken into account to make agents practically usable. In FIPA 97 specification, human-agent interaction as not dealt with, primarily to avoid divergence by considering unlimited issues related to human-agent interaction. Now that FIPA 97 is issued and the scope is clearly delimited, the time is mature for specifying standards for human-agent interaction.
In the reference model of FIPA 98, compliant agents can interact with human users and/or other agents by manipulating user-related information. Compliant agents can offer services related to human-agent interaction; they can assist in managing the dialog between agent and human(s), or they can assist in acquiring, maintaining, and exploiting characteristic information about humans that is required for personalized interaction. That is, in the FIPA 98 reference model, there may be agents specialized on user dialog management or user personalization, although similar functionality may as well be realized within non-specialized agents.
Precisely, the present document specifies:
· a User Dialog Management Service (UDMS) which wraps many types of software components for user interface allowing for ACL level of interaction between agents and human users.
· a User Personalization Service (UPS) which in general allows for registration of, management of and access to user-related information needed for persaonlization. Information may be maintained and accessible as a data-base-like profile, but may also be based on observations of user behavior and constructed by a learning process.
6. Human-Agent Interaction: A Reference Model
In this section, we will put together the issues that we perceive to be important in human-agent interaction. In order to avoid terminological confusion, note that in "human-agent interaction" "agent" refers to a non-human entity, normally implemented in software, and that the "user" is a human (agent) who interacts with such an agent.
 |
Figure 1 Human-agent interaction reference model
Figure 1illustrates the different entities and relationships between entities that are considered crucial to the human-agent interaction process. The figure mainly consists of two parts: on the upper side (which may be regarded as the "user world") there is the user and the interfaces that are available to the user, while on the lower side, we have the "agent world" where agents operate and communicate. We will now describe these both parts in more detail.
6.1. User World
In the user world, a User Dialog Management Service (UDMS) provides two interfaces. One is user interface for human user which serves as interface to a device: a graphical user interface to a computer with its direct manipulation possibilities, a voice interface to a mobile phone, a gesture-based interface to a PDA, etc. Another is agent interface which interacts with agents using the ACL.
So, user dialogue management service translates between user action and the ACL. Internal process of the system is due to implementation, FIPA does not standardize a specification of it. Thus, from the point of view of agents, interacting with the users is not different from interacting with agents.
6.2. Agent World
Via UDMS, interaction is possible between users and agents. Note that no specific functionality is associated with the term "user agent". Any agent that interacts with a human user shall be subsumed by this term.
In Figure 1, the user dialog management service is linked to the Agent Communication Channel (ACC), like all other entities in the agent world.
A crucial part in the intelligent and user-supportive behavior of an agent is played by the model of its user. A user model contains assumptions about user preferences, capabilities, skills, knowledge, etc, which may be acquired by inductive processing based on observations about the user. User models normally contain knowledge bases which are directly manipulated and administered.
In the model, as illustrated in Figure 1, a User Dialog Management Agent (UDMA) interacts with a User Personalization Agent (UPA) via ACC in order to delegate the tasks of user model acquisition, representation, and provision. This agent offers its services to the whole agent world. In particular, one of such services concerns user model learning, which may be exploited to form knowledge about the user from observations, while the other concerns user profiling, i.e., maintaining explicitly formulated knowledge about the user in data-base- or knowledge-base-like formats.
Implementers may have some good reasons for having the user model learning and the user profiling facilities separated from other functionalities. First, powerful mechanisms may be needed to acquire and represent the user models, which may easily grow too complex to be loaded into a typical agent. Moreover, these mechanisms are assumed to be generic enough to be beneficial to more than only one agent. Alternatively, implementers may also choose to directly implement profiling/learning capabilities into their agent architectures.
7. User Dialogue Management Service
7.1. Introduction
In many agent-based systems, there often occurs the need for an agent to interact with a human user. Such interaction may take place via a variety of methods, for example graphical user interface on the user's computer, speech i/o via telephone, or even simple paging. This interaction may be unidirectional (presentation to the user) or bidirectional (sending information to the user and retrieving information from the user). While many systems currently have built-in user interfaces, it is desirable to be able to take advantage of specialised I/O services offered by independent vendors. The mechanisms for offering and selecting such services can in turn best be supported by agent methodology. This section presents an overview of the actions an agent offering a User Dialogue Management Service (UDMS) may perform. Such an agent will be referred to informally in this document as a User Dialogue Management Agent (UDMA).
7.1.1. Background
FIPA 97 defines the term User Agent as an agent acting on behalf of the user. Exactly how the user agent or any other agent for that matter interacts with the user is left up to the system designer. On the other hand, mechanisms are established in FIPA 97 for agents to offer services (via a Directory Facilitator or Agent Resource Broker) and for other agents to request or negotiate about the performance of specific actions according to these services. Making use of the mechanisms offered by FIPA 97, it now becomes possible to offer, select and perform services supporting human-agent interaction.
7.1.2. Motivation
The motivation for this specification is that it allows for user interface services to be provided in an open market. The benefits are in general three fold:
· Creating platform and hardware independence hence giving more portability
· Offering more modalities of interaction hence providing more flexibility
· Leaving the final realisation of the visual (expression) of the user interface to the developer while indicating how the interface can be integrated with a multi-agent system.
7.2. Overview
This section presents an overview of UDMS ontology, fipa-udms. The conceptual designs of the UDMA indicate the abstract workings of agents wishing to interact with a UDMA for human communication. The UDMA’s detailed ontology defines the basic actions necessary for an agent providing a user management dialogue service. As with any action, they may be associated with a particular quality of service and with a particular cost. The execution of these actions are the subject of negotiation between an agent requiring this service and the agent offering the service. A UDMA supplies its UDMS when registering with the directory facilitator. Clearly, a UDMA may have additional capabilities and offer additional services beyond those of user dialogue management. A UDMA need not support all of the described actions. First the conceptual design is illustrated then the lists of actions, protocols and service attributes of the ontology are given.
7.2.1. Conceptual UDMA examples
7.2.1.1.
 |
Scenario 1
Figure 2 Basic UDMA
In Figure 2 is the minimum conceptual UDMA and an example application agent (AA) is illustrated. We make the assumption that the application agent (AA) and the UDMA are registered with the DF. The user is registered with the DF as part of the skills capabilities of the UDMA when it registers itself with the DF (see section service description for detailed specification).
Scenario 1 illustrates the workings of a single UDMA for a single user and is agent driven in that the dialogue is initiated by an agent:
1. AA asks for an agent which can interact with the user from the DF.
2. DF returns the appropriate UDMA.
3. AA contacts the UDMA to communicate with the user and sends the content of the communication to be delivered to Peter.
In order for the UDMA to communicate the content requested for delivery by the AA the content format must be supported by the UDMA. The technical support for this is the UI part. The user interface is integral for the UDMA to supply the services (UDMS) to the application agent.
7.2.1.2. Scenario 2
Scenario 2 illustrates the conceptual design of multiple UDMAs working on behalf of one user.
In this example we are assuming there is at least one UI per UDMA and that each UI is different (e.g. supporting voice, text, video, audio etc.). All these UDMAs are associated with at least one user see Figure 3.
 |
Figure 3: Multiple UDMAs
1. asks for an agent which can interact with the user and can handle the requested output-ontology, (e.g. voice, video) from the DF.
2. DF returns the appropriate UDMA(s).
3. If only one UDMA is returned, AA uses it. This case is the same as scenario 1.
4. If more than one UDMAs are returned, then AA needs to make a choice (the choice may be based on costs, urgency etc.). If AA want to choose a UDMA by which AA can interact the user right now, user identification actions of UDMS will be used. The choice mechanism is totally application dependent.
7.2.1.3. Scenario 3
Scenario 3 illustrates the conceptual design of broker UDMA and multiple UDMAs working on behalf of one user.
We assume here that there is a broker UDMA which can conduct other UDMAs. The conducting UDMA may be called the user's "default UDMA" or "Interface Agent" for convenience. In Figure 4, the default UDMA, UDMA-0 has no UI, however, it may directly have so-called default UI.
In this scenario, UDMAs form a domain called Domain-U by registering to DF-U. Only UDMA-0 registers external DF-A so that AA will use UDMA-0 to interact with the user.
Figure 4: Multiple UDMAs with broker
1. AA asks for an agent which can interact with the user from DF-A.
2. DF-A returns UDMA-0.
3. AA requests user-interactions (e.g. output video) to UDMA-0.
4. UDMA-0 asks DF-U for UDMA(s) which can output the video stream to the user.
5. DF-U returns an appropriate UDMA-1.
6. UDMA-0 requests UDMA-1 to output the video stream.
UDMA-0 may switch several UDMAs or utilize them in parallel for more efficient user interactions, i.e. it may use several human-agent communication channels. User conversation control and user-conversation-id will be used to indicate the human-agent communication channel.
7.2.1.4. Scenario 4
 |
Scenario 4 illustrates the conceptual design of multiple UDMAs for multiple users.
Figure 5: Multiple UDMAs plus multiple users
AA has the same options as stated in scenario 2 but now the UDMA needs to consider how it registers its users with DF (e.g. :user-list (user1 user2)). Also AA may have to check who is currently available to interact by user identification actions. UDMA will need to manage an internal model of how to contact each user.