Contents
1 Scope.......................................................................................................................................... 3
2 Normative references................................................................................................................... 3
3 Terms and definitions................................................................................................................. 3
4 Symbols (and abbreviated terms)................................................................................................ 3
5 General Analysis......................................................................................................................... 3
5.1 Introduction................................................................................................................................ 3
5.2 Problem Statements.................................................................................................................... 3
5.3 Business Domain analysis.......................................................................................................... 3
5.4 Actors and Roles......................................................................................................................... 3
5.5 Overall Scenario.......................................................................................................................... 3
5.6 External Software Integration...................................................................................................... 3
5.7 Internal Software (Degrees and Types of Intelligence).................................................................. 3
5.8 Internal Capabilities.................................................................................................................... 3
5.9 Human-Agent Interface................................................................................................................ 3
5.10 Agent Management...................................................................................................................... 3
6 Architecture................................................................................................................................. 3
6.1 Services Architecture and Protocols............................................................................................ 3
6.2 Agent Definitions......................................................................................................................... 3
6.2.1 Mini-PTA..................................................................................................................................... 3
6.2.2 Personal Travel Agent................................................................................................................. 3
6.2.3 Travel Broker............................................................................................................................... 3
6.2.4 Tourist Office Broker................................................................................................................... 3
6.2.5 Flight Service Provider................................................................................................................ 3
6.2.6 Web Service Provider.................................................................................................................. 3
6.3 Platform Profiles......................................................................................................................... 3
6.3.2 Travel Broker Agent Platform...................................................................................................... 3
6.3.3 Agent „Hotel“ Platform (on-trip
execution).................................................................................. 3
6.3.4 Domain Structures...................................................................................................................... 3
7 Ontology..................................................................................................................................... 3
7.1 Content....................................................................................................................................... 3
7.1.1 Trip Summary............................................................................................................................. 3
7.1.2 Trip Details.................................................................................................................................. 3
7.1.3 Exception.................................................................................................................................... 3
7.2 Operations.................................................................................................................................. 3
7.3 Negotiation.................................................................................................................................. 3
7.4 Elaboration of User-profile.......................................................................................................... 3
8 Study cases................................................................................................................................. 3
8.1 Agent Domain Boot Process........................................................................................................ 3
8.2 Pre-trip planning......................................................................................................................... 3
8.3 Elaboration of Pre-trip Planning.................................................................................................. 3
8.4 Last-minute Auction for Lower Fare............................................................................................. 3
8.5 On-trip execution......................................................................................................................... 3
8.6 Travel Plan Monitoring................................................................................................................ 3
9 Examples of Agent/Software Integration...................................................................................... 3
9.1 Web-based fare wrapper.............................................................................................................. 3
9.1.1 Registration of wrapper............................................................................................................... 3
9.1.2 Agent request for price................................................................................................................ 3
9.1.3 Notification of price change......................................................................................................... 3
9.1.4 Internal procedural attachment.................................................................................................... 3
9.2 BAYERNInfo service wrapper...................................................................................................... 3
9.2.1 Agent request for route................................................................................................................ 3
10 Future PTA Developments........................................................................................................... 3
10.1 "Migrating" Agent to
Guide Travelling User................................................................................. 3
10.1.1 Mobility of the agent in a network:
travel planning...................................................................... 3
10.1.2 Mobility of the traveller: travel
monitoring................................................................................... 3
10.1.3 Mobility of the traveller: travel
monitoring via UMTS................................................................... 3
10.2 Inter-operation between Agents and
Workflow............................................................................. 3
11 Informative References................................................................................................................ 3
Foreword
The Foundation for Intelligent
Physical Agents (FIPA) is a non-profit association registered in Geneva,
Switzerland. FIPA’s purpose is to promote the success of emerging agent-based
applications, services and equipment. This goal is pursued by making available
in a timely manner, internationally agreed specifications that maximise
inter-operability across agent-based applications, services and equipment. This
is realised through the open international collaboration of member
organisations, which are companies and universities active in the agent field.
FIPA intends to make the results of its activities available to all interested
parties and to contribute the results of its activities to appropriate formal
standards bodies.
This specification has been
developed through direct involvement of the FIPA membership. The 35 corporate
members of FIPA (October 1997) represent 12 countries from all over the world
Membership in FIPA is open to any
corporation and individual firm, partnership, governmental body or
international organisation without restriction. By joining FIPA each Member
declares himself individually and collectively committed to open competition in
the development of agent-based applications, services and equipment. Associate
Member status is usually chosen by those entities who do want to be members of
FIPA without using the right to influence the precise content of the
specifications through voting.
The Members are not restricted in
any way from designing, developing, marketing and/or procuring agent-based applications,
services and equipment. Members are not bound to implement or use specific
agent-based standards, recommendations and FIPA specifications by virtue of
their participation in FIPA.
This specification is published as
FIPA 97 ver. 1.0 after two previous versions have been subject to public comments
following disclosure on the WWW. It has undergone intense review by members as
well non-members. FIPA is now starting a validation phase by encouraging its
members to carry out field trials that are based on this specification. During
1998 FIPA will publish FIPA 97 ver. 2.0 that will incorporate whatever
adaptations will be deemed necessary to take into account the results of field
trials.
Introduction
This FIPA 97 specification is the
first output of the Foundation for Intelligent Physical Agents. It provides
specification of basic agent technologies that can be integrated by agent
systems developers to make complex systems with a high degree of
inter-operability.
FIPA specifies the interfaces of
the different components in the environment with which an agent can interact,
i.e. humans, other agents, non-agent software and the physical world. See
figure below
FIPA produces two kinds of specification
·
normative specifications that mandate
the external behaviour of an agent and ensure inter-operability with other
FIPA-specified subsystems;
·
informative specifications of
applications for guidance to industry on the use of FIPA technologies.
The first set
of specifications – called FIPA 97 – has seven parts:
·
three normative parts for basic agent
technologies: agent management, agent communication language and
agent/software integration
·
four informative application
descriptions that provide examples of how the normative items can be applied:
personal travel assistance, personal assistant, audio-visual entertainment and
broadcasting and network management and provisioning.
Overall, the three FIPA 97
technologies allow:
·
the construction and management of an
agent system composed of different agents, possibly built by different developers;
·
agents to communicate and interact
with each other to achieve individual or common goals;
·
legacy software or new non-agent
software systems to be used by agents.
A brief
illustration of FIPA 97 specification is given below
Part 1 Agent
Management
This part of
FIPA 97 provides a normative framework within which FIPA compliant agents can
exist, operate and be managed.
It defines an
agent platform reference model containing such capabilities as white and yellow
pages, message routing and life-cycle management. True to the FIPA approach,
these capabilities are themselves intelligent agents using formally sound communicative
acts based on special message sets. An appropriate ontology and content
language allows agents to discover each other’s capabilities.
Part 2 Agent
Communication Language
The FIPA
Agent Communication Language (ACL) is based on speech act theory: messages are
actions, or communicative acts, as
they are intended to perform some action by virtue of being sent. The
specification consists of a set of message types and the description of their pragmatics,
that is the effects on the mental attitudes of the sender and receiver agents.
Every communicative act is described with both a normative form and a formal
semantics based on modal logic.
The
specifications include guidance to users who are already familiar with KQML in
order to facilitate migration to the FIPA ACL.
The
specification also provides the normative description of a set of high-level
interaction protocols, including requesting an action, contract net and several
kinds of auctions etc.
Part 3
Agent/Software Integration
This part
applies to any other non-agentised software with which agents need to
„connect“. Such software includes legacy software, conventional database
systems, middleware for all manners of interaction including hardware drivers.
Because in most significant applications, non-agentised software may dominate
software agents, part 3 provides important normative statements. It suggests
ways by which Agents may connect to software via „wrappers“ including specifications
of the wrapper ontology and the software dynamic registration mechanism. For
this purpose, an Agent Resource Broker (ARB) service is defined which allows
advertisement of non-agent services in the agent domain and management of their
use by other agents, such as negotiation of parameters (e.g. cost and
priority), authentication and permission.
Part 4 -
Personal Travel Assistance
The travel
industry involves many components such as content providers, brokers, and
personalisation services, typically from many different companies. In applying
agents to this industry, various implementations from various vendors must
inter-operate and dynamically discover each other as different services come
and go. Agents operating on behalf of their users can provide assistance in the
pre-trip planning phase, as well as during the on-trip execution phase. A
system supporting these services is called a PTA (Personal Travel Agent).
In order to
accomplish this assistance, the PTA interacts with the user and with other
agents, representing the available travel services. The agent system is
responsible for the configuration and delivery - at the right time, cost,
Quality of Service, and appropriate security and privacy measures - of trip
planning and guidance services. It provides examples of agent technologies for
both the hard requirements of travel such as airline, hotel, and car arrangements
as well as the soft added-value services according to personal profiles, e.g.
interests in sports, theatre, or other attractions and events.
Part 5 -
Personal Assistant
One central class of
intelligent agents is that of a personal assistant (PA). It is a software agent
that acts semi-autonomously for and on behalf of a user, modelling the
interests of the user and providing services to the user or other people and
PAs as and when required. These services include managing a user's diary,
filtering and sorting e-mail, managing the user's activities, locating and
delivering (multi-media) information, and planning entertainment and travel. It
is like a secretary, it accomplishes routine support tasks to allow the user to
concentrate on the real job, it is unobtrusive but ready when needed, rich in
knowledge about user and work. Some of the services may be provided by other
agents (e.g. the PTA) or systems, the Personal Assistant acts as an interface
between the user and these systems.
In the
FIPA'97 test application, a Personal Assistant offers the user a unified,
intelligent interface to the management of his personal meeting schedule. The
PA is capable of setting up meetings with several participants, possibly
involving travel for some of them. In this way FIPA is opening up a road for
adding inter-operability and agent capabilities to the already established
Part 6 -
Audio/Video Entertainment & Broadcasting
An effective
means of information filtering and retrieval, in particular for digital
broadcasting networks, is of great importance because the selection and/or
storage of one’s favourite choice from plenty of programs on offer can be very
impractical. The information should be provided in a customised manner, to
better suit the user’s personal preferences and the human interaction with the
system should be as simple and intuitive as possible. Key functionalities such
as profiling, filtering, retrieving, and interfacing can be made more effective
and reliable by the use of agent technologies.
Overall, the
application provides to the user an intelligent interface with new and improved
functionalities for the negotiation, filtering, and retrieval of audio-visual
information. This set of functionalities can be achieved by collaboration
between a user agent and content/service provider agent.
Part 7 - Network
management & provisioning
Across the
world, numerous service providers emerge that combine service elements from
different network providers in order to provide a single service to the end
customer. The ultimate goal of all parties involved is to find the best deals
available in terms of Quality of Service and cost. Intelligent Agent technology
is promising in the sense that it will facilitate automatic negotiation of
appropriate deals and configuration of services at different levels.
Part 7 of
FIPA 1997 utilises agent technology to provide dynamic Virtual Private Network
(VPN) services where a user wants to set up a multi-media connection with
several other users.
The service
is delivered to the end customer using co-operating and negotiating specialised
agents. Three types of agents are used that represent the interests of the
different parties involved:
·
The Personal Communications Agent
(PCA) that represents the interests of the human users.
·
The Service Provider Agent (SPA) that
represents the interests of the Service Provider.
·
The Network Provider Agent (NPA) that
represents the interests of the Network Provider.
The service
is established by the initiating user who requests the service from its PCA.
The PCA negotiates in with available SPAs to obtain the best deal available.
The SPA will in turn negotiate with the NPAs to obtain the optimal solution and
to configure the service at network level. Both SPA and NPA communicate with
underlying service- and network management systems to configure the underlying
networks for the service.
1 Scope
This document adds to the FIPA 1997 standard for
inter-operating agents and agent societies by providing an application specification
for the travel industry. This document provides
¾
An overview of the current industry in
regard to agents;
¾
A reference architecture for a
multi-agent system in this industry;
¾
Examples of the agent management
details such as domains and naming;
¾
Examples of agent communication
details such as content ontologies and communication protocols;
¾
Examples of agent/software integration
such as for accessing databases and mobile users
This document does not pretend to be a complete
specification of this large and complex industry, but such examples help to
illustrate the use of FIPA 1997 standard and thereby quicken the development
and deployment of real systems. On the other hand, some points of this
architecture have been selected as semi-normative
requirements for field trails in order to begin inter-operability tests of such
trials in 1998. These requirements are noted throughout the document as they
arise.
In summary, this document servers three purposes:
¾
Continue testing the FIPA technical
specifications. The context of a real application serves to determine the
strengths and weaknesses of the specifications.
¾
Demonstrate the real business value --
and requirement -- of a standard specification for such a large, distributed,
multi-vendor application.
¾
Define initial application
architecture, object design and use case analysis for actual development of
field trials (see FIPA7604).
The number of agents and types of vendor in this
application are beyond a complete specification in this document. The scope of
the document is large, but serves only as a broad outline for actual
development by individual vendors.
2 Normative references
The following references are cited in this document.
The FIPA standards are required for all field test based on this specification.
All other standards are here used as examples. The specific field trials will
determine which of these examples (or other standards) are most appropriate for
the members involved (see FIPA7604 for current assumptions).
FIPA 1997 Part 1: Agent Management, Part 2: Agent
Communication Language, and Part 3: Agent/Software Integration.
Geographic Data Files. European
Committee for Standardisation for GeoPoints
ISO 639 for Language names.
ISO 3166 for Country names.
ISO 8601 for Date/time format
3 Terms and
definitions
Provider
In the provider role, an organisation interfaces with a customer to
agree to the provision of a service. This will involve producing a contract
which records the conditions under which a service will be provided, and which
will be agreed to by both the provider and customer.
Service provider
It is an entity that provides either telecommunications services,
information services or both, as well as applications services. In the
definition of service provider we address only services available on the
network. In this case there are two types of services, services which are the
subject of the brokerage (Travel Information Brokerage) and supporting services
(security, billing, certificates).
Content provider
It is an entity that offers negotiable services or goods to users -
directly or by the means of a brokerage service.
Network provider
It is an entity that provides all necessary networking functions to
others actors.
Customer
In the customer role an organisation or individual interfaces with a
provider organisation to procure services. Within this role the organisation or
individual enters into a contract with a provider for the purpose of procuring
services.
User
In the user role an organisation or individual uses a service
procured from another organisation. Such use will be based on conditions laid
down in a contract which was agreed between the organisation acting in a
customer role and the other organisation acting in a provider role. The service
can be a management service in which case the responsibility for the role would
contain the responsibilities entailed by those services. The distinction
between a customer and a user, is that the former defines the type and scope of
the service made available by the provider through negotiation, whereas the
latter uses the service within these agreed parameters.
4 Symbols (and abbreviated terms)
GPS: Global Position System.
GSM: Global
Systems for Mobile Communication.
HTTP: Hyper-Text
Transfer Protocol, a commonly used protocol to transfer documents on the
world wide web.
IIOP: Internet-interorb
Protocol. See OMG
OMG: Object Management Group
OPS. Open Profiling Standard.
QoS:
Quality of Service.
PA: Personal
Assistant. See FIPA 1997 Part 5. PAs are expected to also participate in
the PTA system.
PDA Personal
Digital Assistant Small computing device, not an agent per se.
PTA: Personal
Travel Assistance
UMTS Universal
Mobile Telecommunication System
XML:
Extended Markup Language.
5 General
Analysis
5.1 Introduction
A wide variety of travel related services are
becoming increasingly available through electronic means. There is a need for
convenient and ready access to these services, in particular for travellers.
This presents a prime example to showcase the benefits of agent technology.
Agents operating on behalf of their users can provide assistance in the
pre-trip planning phase, as well as during the on-trip execution phase of a
trip. A system supporting these services is called a PTA system.
In order to accomplish this assistance, these
agents will interact with the user and with other agents representing the
available travel services. The agent system is responsible for the
configuration and delivery - including the right time, cost, QoS, and appropriate
security and privacy measures - of trip planning and guidance services (e.g.
multi-modal route planning, hotel and parking-lot reservations, individualised
traffic guidance, cartography services, tourism information, plane reservation,
metro guidance, weather conditions, public transportation, special events,
Arts,...). Further, there is interaction with other supporting agents such as
media agents, directory services (yellow and white pages), and information
brokers that seek, evaluate and deliberate on information.
Figure 1 A scene from FIPA enabling applications
The PTA system should support the following
core functionalities:
¾
Different modes for request/response.
The user does not need to be connected while a request completed;
¾
Composition of services. The system
should provide an integrated experience even though the component services are
disparate.
¾
Comparison of service offerings. The
system should evaluate and provide the user with different service dimensions
such as cost or other user’s experience.
¾
Learning the user profile. The system
should become more efficient toward the user’s needs and habits with continued
experience.
¾
Inter-operability of communication
means. The same underlying services should be available through many different
media such as voice-phone, pager, e-mail, screen-phones, and Web.
¾
Administration of agents. The system
and user will need the ability to follow-up agents or otherwise change their
behaviour at any time.
¾
Alerts. The user should be notified of
significant events.
¾
Negotiation and transactions. The
system should act on the user’s behalf to make deals and commit to purchases,
for example.
This list of functions includes connectivity to
basic services such as email as well as emerging services in e-commerce such as
advertising and web casting. The PTA domain is rich with many basic and
emerging possibilities, but for focus in this document, two test scenarios are
developed, which represent the two basic phases of agent support:
¾
Pre-trip planning. The activities made
in preparation for a trip, such as booking flights and hotels.
¾
On-trip execution. The activities
required during a trip for successful execution such as monitoring the schedule
and making changes to bookings as required.
Focusing on these primary scenarios, this
document includes an overall outline of the agent types and roles, and the
software and devices required for both phases. For instance, on-trip execution
introduces the potential use of PDAs and the agents' attachments to cellular or
GSM-based phones and GPS services. Other secondary scenarios are included in
this document to demonstrate other aspects of the FIPA 1997 specifications; for
instance, parts of an agent’s lifecycle and special focus of mobility will be
included.
Travel is an excellent application to
demonstrate because it includes so many external attachments that are of interest
to many other applications. For instance, the Travel scenario will include
¾
Information Retrieval. Travel services
provide both database and Web-based access and search
¾
Scheduling. Travel not only includes
scheduling within its own domain, travel schedules must also interact with
personal calendars and schedules. Calendar tools, e-mail, and other general
office applications are required.
¾
End-user Mobility. Not to be confused
with agent mobility, travel implies several mobile device modalities and problems
of communication in connected/disconnected states
¾
Agent mobility. Because of user
mobility, agent mobility is often indicated for the transfer of binary or
script code through the network
Moreover, the Travel scenario includes very
strong testing of agent-to-agent attachment and the internal capacities to
support different agent roles. For instance, the following agent-based
technologies are also of very general interest:
¾
Combined or Competitive Services.
Compare attributes, negotiate cost and time
¾
User Profiling. Personal preferences,
adaptive user modelling
The latter issue is not directly addressed by
the FIPA 97 standard, but is critical to Travel and several other end-user
driven applications. It should be addressed more in the future (also see OPS).
5.2 Problem
Statements
The application of agents to the Travel
industry exposes some very important problems now being faced by agent developers
and applications in many other industries as well:
¾
Web-based and Database-based
Publication: As the travel service providers move from database to web-based
pricing, for instance, agent developers are faced with the problems of HTML
parsing. While this method is workable, it is very sensitive to minor and
peripheral format changes. All agents of all vendors must spend a great deal of
effort to maintain the agents' proper attachment. Both the database-based and
Web-based content can include "agentised" mediation. Aside from some
re-publication issues, one or a few agent-based services can parse and
otherwise "logicise" the raw data, offering this service to other
agents. Other solutions, such as XML tags for ontology and content are very
sympathetic to agent development, and future Web-based service providers might
directly provide the agent-based service as well, but in any case, other agents
from other vendors should rely on a well-founded communication standard at the level
of agents.
¾
Complexity of Market (De)Regulations:
Travel policy (especially in world-wide travel) is complex and often unknown to
human travel agents. These policies are highly distributed, from corporate
policy to agency policy to national and international law. The representation
and use of such policies is a fairly straight-forward knowledge engineering
task. A distributed agent approach seems required to partition the problem and
allow different vendors to provide different parts of the solution so that
every agent in the system needs not carry all the responsibility.
¾
Complexity of Real-world Transactions:
Travel planning is really a "super-transaction" of many negotiations.
A service cannot merely find low fare, because lower fare is only one of many
hard and soft constraints. A transaction cannot be based or concluded only for
flight arrangements, because hotel, car, and many personal arrangements must
also be established. To provide real value, a service should also be suggestive
-- beyond the direct travel needs and the Personal Travel Assistance Services
should collectively provide the end user with a complete travel package, not
just the minimal travel documents. It should contribute for market expansion
into other segments.
This last problem suggests the need to
co-ordinate the transactions using agent-based protocols such as Contract Net
and internal technologies such as incremental scheduling. Because these are
very specialised techniques, the FIPA design philosophies for agent software
integration and agent interaction provide a solution by distributing the
responsibilities; PTA is a very large and difficult problem, best solved by
vendor specialists in internal agent technologies, external software domains,
and agent-to-agent protocols that can work together.
To summarise, the PTA services should provide
an effective testbed of the technology-oriented normative parts of the FIPA
1997 standard.
5.3 Business
Domain analysis
Although the business analysis will not be
fully developed in this document, it will give a hint of a generic Business
Model of the PTA application. This viewpoint is on a system focus: on the
purpose, scope and policies for the system. It can be modelled in terms of
objects representing user roles, business and management policies. This viewpoint
is concerned with the overall environment in which a system is to operate. In
our case it spans co-operating organisations. In general the following figure
represents the separate business domains.
Figure
2. Relationships between Business Domains
This model can be used as a framework for:
¾
Analysing the organisational
environment. This mainly includes network operators, service providers and
customers. Which actors are involved and how do they relate to each other, i.e.
their roles, their domains of activity, the inter-domain policies (security,
billing), and what are the interactions between the system and the environment
in which it is placed?
¾
Defining the requirements of actors.
For instance, what are the requirements between customers with respect to
providers, i.e. contractual relationships properties (security aspects,
payment, QoS, ... )?
In each role, an actor performs different types of provisioning
activities. Identifying these helps distinguish between different parts of an
organisation and can indicate the types business and management support
required.
5.4 Actors
and Roles
This section derives definitions for each actor-agent involved in
the travel brokerage service and identifies their roles.
Travel
Service Agent(s)
These
service agents are responsible for attachment to the data of their domain. The
scope of each domain is arbitrary, but each such agent would tend to specialise
in global flight plans and hotel arrangements or local hotel, car, and restaurant
information. Other services might specialise in tourism or restaurants, for
example, but globally. In either case, providing such "soft" added
value about museums, theme parks, and special events/offers should be a strong
part of agent co-operativity to build a more complete travel plan for the user.
In all
cases, this agent type is responsible for maintaining the data access,
interpretation and delivery to other agents. Such agents would typically use
search services, too, in order to keep themselves up to date or to provide
integrated / agentised search within the a travel domain to other agents. Any
such agent service might be implemented as a "wrapper" around legacy
databases or WWW page content. New services can be directly agentised, but this
distinction is transparent to other agents.
Travel
Broker Agent(s)
This
agent is responsible to locating and contracting with Travel Service Agents. It
can obtain the travel options from several services, filter and select from the
alternatives, and legally bind a contract and travel documents based on a final
selection. It can schedule and incrementally reschedule the entire travel plan
across several service types (flight, train, hotel, special events).
This
agent type provides its service to any "anonymous" user. In other
words, its service connection with the user is only for the life of the super
transaction; it does not serve as the personal agent to any one user and does
not keep any persistent information about particular users, aside from its own auditing/logging
needs.
Personal
Travel Assistant
This
agent acts on behalf of a user. It is legally authorised to act on behalf of
the user, to the level allowed by the user. While conceptually seen as one
personal assistant for each user, the implementation should be assumed to use a
multi-user, server-based design. This agent type has many similarities to a
Personal Assistant and might simply be a "cast" of it. This agent is
responsible for remembering and following the user's instructions and learning the
user's preferences based on choices or feedback after the trip.
Mini
Personal Travel Assistant
This
lightweight agent is typically very device-dependent, such as an agent
operating on a PDA or laptop. For instance, bandwidth and modality become
special issues. Although this tends to cause restriction of functionality, many
additional functions such as GPS and GSM could be provided.
Some assumptions about these responsibilities might be changed or
elaborated. For instance, the Travel Broker might maintain some of the personal
information of users, such as simple travel preferences (airline seating, smoking
or not). Also, value-added service can be provided by many different
arrangements. For instance, the communication of the Mini Travel Assistant into
the network-based agents can be various. Does the user/MiniPTA contact the
Broker directly on the road or always go through the PTA? Can the user directly
contact the Broker? Is the Personal Travel Assistant really a sub-function of a
Personal Assistant (like a personal secretary)?
Each project will determine the answers to these questions, but for
initial field trails of FIPA 1997 standards, this document will assume that
Travel Broker Agent (as defined in this document) will interact with Personal
Assistants (as defined in FIPA 1997 Part Five). The Personal Assistant will
take the role of Personal Travel Assistant. In either case, the following
scenario is primary for such field trails.
5.5 Overall
Scenario
The typical dialogue between real users and travel agencies will be
used as a guiding metaphor:
1) The user asks his/her secretary to make
travel reservations for the next day. The user delegates the task to the agent.
The agent is generally autonomous and bothers the user only for confirmation or
in exception conditions. Time constraints for completion of this task might be
explicitly stated or assumed according to the travel attributes or personal
preferences (past history).
2) The secretary calls a Travel Agency. In the
simplest case, the user's company might be pre-contracted with only one Agency,
or the secretary might have some choice, but only
within a list of approved and registered agencies. Assume that there is some
sort of accreditation or professional membership that ensures/suggests competency.
3) The Travel Agency contacts several providers
of services to build a complete plan. The Travel agent maintains a dialogue
with the secretary, who has a better sense of the user, validates how the
travel documents should be delivered, etc.
4) The secretary reports back to the user with a
plan, options, and additional information. The secretary places the schedule
with some travel information on the user's calendar, perhaps also setting
reminders for when the user should leave to catch the flight.
5.6 External
Software Integration
These different agent types have varying levels of integration to
external software and/or other agents. For instance, Travel Service Agent
responsibilities are most for attachment to data sources, whereas a Broker
Agent's function is more abstract and more responsible to managing agent
interactions. The following table lists only external software attachments.
Table
1 External Attachments for Different Agent Types
|
Agent Type
|
Possible Software
Attachments
|
|
Travel Service Agent
|
Existing Travel DB Services
HTTP/HTML (for Web-based content)
Broadcast protocols (e.g. RDS, DAB, ... )
Search Service (one or many, web-based or not)
|
|
Travel Broker Agent
|
Yellow-Page Directory (e.g. LDAP)
White-Page Directory (e.g. LDAP)
|
|
Personal Travel Assistant
|
GSM (cell phone) Protocol
Email
Calendar / Scheduling
Fax
E-commerce (Cyber cash or others)
Video server
|
|
Mini-Personal Travel Assistant
|
GSM Protocol
GPS/Cartography
Pager
|
Note that the Travel Broker Agent uses directory services but
provides much more. More than a directory service alone, a Broker is itself an
agent and can provide the negotiation and consolidation of services as an
added-value. Also note how the PTA might provide travelogue video services;
although a Personal Assistant can also talk directly to a Broker, this is the
kind of added value within a particular industry focus that a PTA can uniquely
provide. This list is by no means exhaustive, but gives some idea of the
integration components required and how these components might be reusable in
other domains aside from Travel.
5.7 Internal
Software (Degrees and Types of Intelligence)
Although FIPA 1997 has deferred the distinction between external and
internal components, this document provides some examples and guidance.
For instance, there are two approaches. First, special internal
engines such as for scheduling or learning can use the Agent/Software
Integration standard of FIPA 1997 to attach such components to the agent. The
internal reasonings of the agent can control other external and internal
components equally. At least, applications can test this hypothesis: whether or
not the external wrapper interface can be used to attach internal capabilities
of the agent to each other as well.
Second, any special intelligence function can be made into a first
class agent that provides such scheduling or translation of learning services.
This approach too should be tested with different applications and compared
with the first approach.
In some regards, the two approaches are very internal components of
intelligence to be viewed recursively -- an large-grained agent's internal
composition is a "society of minds" based on smaller, semantically
simpler agents. Wrappers are much like very simple agents using a subset of communicative
acts.
These notions need further specification and test, but for this PTA
application, the following internal capabilities seem to imply certain internal
components and its is assumed that such components would be included as components
in the explicitly named agents of the PTA system.
5.8 Internal
Capabilities
As mentioned below, internal capabilities are not mentioned by the
FIPA 1997 standard but are important considerations for the application design.
The following table lists the types of technology the agents are likely to
require to serve each of their purposes.
Table
2. Internal Capabilities of Different Agent Types
|
Agent Type
|
Possible Internal
Capability
|
|
Travel Service Agent
|
Rule-based inferencing
Procedural scripting
|
|
Travel Broker Agent
|
Rule-based policy and planning
Contract-net
Rationality
Acquaintance Modelling
|
|
Personal Travel Assistant
|
Rule sets
Preference facts based on end-user instruction
Learning for adaptive user model
|
|
Mini Personal Travel Assistant
|
Some micro-kernel capabilities, especially for user interaction,
need local installation
Server-loadable procedures such as Java binary code or script
(dynamic "brains")
|
Travel Service Agents have simple requirements; they typically will
respond to requests for information. Simple rule based or even scripting
systems for the most basic services will be typical.
Travel Broker Agents are probably the most complex agents. They must
adhere to industry and owner policies. They should follow a number of
co-operation and negotiation protocols. This is the most appropriate place for
rational agents that can understand and respond very flexibly to any number of
different situations. As included in the scenarios below, the Broker Agents
should maintain an acquaintance model, such as for management of long-term
associations with other agents.
As for the Personal Agents, basic inferencing is probably
appropriate, but the addition of end-user modelling (learning) will be of
increasing importance in such agents. The Mini-PTA is more peculiar. It should
act much like the PTA, but given the device sizes it must live on, the Mini-PTA
per se needs to be more minimal and rely on networking to other agents to
provide its intelligence as perceived by the user. Some core capabilities will
need to be installed, but aside from communications with other agents,
alternative architectures employing mobile code can dynamically load the
Mini-PTA as needed.
5.9 Human-Agent
Interface
While the fundamentals of human-agent and agent-agent interaction
should be based on the same underlying formal dialogue model, the entire set of
FIPA technologies at this point does not seem to support the full application
development. Particularly, there are neither standard interfaces and component
definitions for supporting the graphical/text and/or voice/speech interface
directly at the end-user, nor translation tools from these "natural"
representations to the formal model. To compensate, the above scenario assumed
a highly restrictive end-user input form, which would have to be tightly
coupled to the dialogue representation.
A very important issue to consider is the "just necessary
level" of user interaction. How is this established? By standard user
interface controls and techniques? This problem requires specialised studies to
define just necessary level: how are user preferences established and how do
preferences interact with task complexity. Acceptability of the Personal Travel
Assistant -- and all other assistants -- will be based largely on matters of
trust and control.
Even though human-agent dialogue tools are not now specified by
FIPA, this application specification includes a Dialogue Wrapper, which
translates any software user-interface events and media applications into FIPA
compliant communicative acts and content within the agent.
5.10 Agent
Management
Life cycle management is the first concern of the PTA system, even
before the system is deployed. The domain definitions, agent naming, and
registrations must be handled first.
PTA requirements for e-commerce and personal profile give great need
to addressing security. Basic services for ensuring the financial transaction
and certification of documents are required. Much of this can be assumed by appropriate
use of the underlying protocol (SSL or SHTTP, for example). FIPA and the PTA Ontology in this document do not provide for
electronic commerce directly, but Agent Management does provide basic
authentication mechanisms.
Because Agent Management directly
represents the application architecture, the following section starts to
provide more explicit designs as examples of Agent Management.
6 Architecture
6.1 Services Architecture and Protocols
The PTA architecture should act as
a reference model which identifies and characterises the components, interfaces,
and protocols. The following diagram shows the general application architecture
of the pre-trip planning system.
Figure 3. PTA Architecture
The diagram represents the various
agent types and the communication types between them. This section provides a
description of representative agents, some representative platforms, and then
the protocols between them. Conventions such as for agent naming will be
followed as they are developed by the Agent Management specification, but note
that much of what is below is deliberately inconsistent (when consistency is
not required) to demonstrate the probable state of multi-vendor vagaries.
6.2 Agent Definitions
Assume that a small company,
CompanyXYZ, has installed an agent platform in which a multi-user
implementation of a PTA is added. Each employee also is given a PDA with a
mini-PTA. CompanyXYZ has agreements and policies to use World Travel Agency
business travel. As an added value to its employees, CompanyXYZ has also developed
its PTA to look-up value-added brokers to arrange for their personal interests,
as well. These agencies are associated with various basic service providers.
6.2.1 Mini-PTA
|
:agent-name
|
Mini-pta.joesmith@CompanyXYZ.com
|
|
:agent-type
|
PTA-mini
|
|
:agent-services
|
:service-ontology user :service-description
(notify | available)
:service-ontology
pta :service-description :location
|
|
:interaction-protocols
|
Fipa-request
|
|
:ontology
|
User
PTA
|
|
:address
|
Gsm://minipta/~smith.1
|
|
:ownership
|
Joe Smith
|
Joe Smith is given a mini-PTA
because he travels a lot for Company XYZ. Because of its limited capacity, it
understands only fipa-request protocol, but can provide unique service to the
entire PTA system of agents. Assuming an ontology called user, it can handle
the operation of notifying the user, if he/she is available. For on-trip
monitoring, it can provide :location of itself, through its GPS attachment
for example.
6.2.2 Personal Travel Agent
|
:agent-name
|
Pta@CompanyXYZ.com
|
|
:agent-type
|
PTA-personal-travel-agent
|
|
:agent-services
|
:service-ontology PTA :service-description
:service-ontology
user :service-description PersonalInterests
|
|
:interaction-protocols
|
Fipa-contract-net
Fipa-auction-dutch
Fipa-request
|
|
:ontology
|
PTA
|
|
:address
|
iiop://companyxyz.allagents:9000/acc
|
|
:ownership
|
Company XYX Limited Partnership
|
Assume that a small company such as
XYZ would have only one personal travel agent as a multi-user system to service
its entire staff. As a small company, XYZ allows any flights with any carrier
in order to get the cheapest fare and therefore, this PTA can follow Dutch
auctions as well as contract net for conversation – either with brokers or with
service providers directly. The company itself owns this PTA in order to
control it in regard to corporate travel policies for example. Not only does
the PTA handle the PTA ontology for making regular travel arrangements, note
that it only understands user profiling. Residing on a server, the PTA is
responsible for holding such personal profiling information (common travel
preferences as well recreational interests perhaps).
6.2.3 Travel Broker
|
:agent-name
|
TravelAgent76@WorldTravel.
|
|
:agent-type
|
PTA-broker
|
|
:agent-services
|
…
|
|
:interaction-protocols
|
FIPA-contract-net
FIPA-request-when
|
|
:ontology
|
PTA
|
|
:address
|
iiop://worldtravel.brokers:9000/brokeracc
|
|
:ownership
|
World Travel Incorporated
|
As a large travel company,
WorldTravel has a bank of several agents. This is number 76. As a broker, this
agent understands contract-net for negotiating basic travel arrangements, but
also provides monitoring functions for its customers by using the request-when
protocol with its service providers. For instance, when a certain condition
occurs concerning a reservation or the availability of a resource, the travel
broker is notified and can in turn notify other acquaintances.
6.2.4 Tourist Office Broker
|
:agent-name
|
Touragent@tokyotourism.com
|
|
:agent-type
|
PTA-broker
|
|
:agent-services
|
…
|
|
:interaction-protocols
|
FIPA-request
|
|
:ontology
|
User-PersonalInterest
|
|
:address
|
iiop://toyko.tourism.broker:9000/acc
|
|
:ownership
|
Tokyo Tourism Bureau
|
A tourist office in Tokyo with a
small budget wants to participate in the PTA system by registering its agent
with several brokers as a free value-added source of information. It is itself
of broker of other agents in its geography, but it is informational only. For
instance, given a user’s personal interests, it can connect a PTA to an
appropriate soft-service agent. It might also provide information about these
soft services but does no transaction itself; it only needs the FIPA-request
protocol.
6.2.5 Flight Service Provider
|
:agent-name
|
Domestic389@flightplanners.foil.com
|
|
:agent-type
|
PTA-server
|
|
:agent-services
|
:service-ontology PTA
:service-description ( reserve | purchase )
(PTA-MeanType :plane)
:language KIF1.0
|
|
:interaction-protocols
|
Fipa-contract-net
|
|
:ontology
|
PTA
|
|
:address
|
Iiop://FOIL.planners:9000/brokeracc
|
|
:ownership
|
FOIL Incorporated
|
A very large flight reservation
company maintains a number of agents, some for domestic travel and some for
international. It can make reservations or accept purchase for flights, but for
flights only.
6.2.6 Web Service Provider
|
:agent-name
|
Gardenguide@kewtgardens.com
|
|
:agent-type
|
PTA-server
|
|
:agent-services
|
:service-ontology
PTA :service-description (contains :pointOfInterest Gardening)
|
|
:interaction-protocols
|
Fipa-request
|
|
:ontology
|
Yahoo
PTA
|
|
:address
|
http://kewt.agents:9000/guideacc
|
|
:ownership
|
Kewt Gardens
|
