Agent Communication

Languages: Past, Present

and Future
Yannis Labrou

Visiting Assistant Professor

University of Maryland
Baltimore County

Director of Technology
PowerMarket, Inc.

© 2000
 Tutorial Objectives
• Present the general requirements of agent
communication languages
• Sketch their conceptual and theoretical
underpinnings
• Describe some current languages and
their realizations in software
implementations
• FIPA standardization efforts
• Discuss trends and future directions
Introduction to Agents
& Agent
Communication
Agents: A system-building paradigm

Distributed Information
Systems Retrieval

Mobile code agents AI & Cognitive

Science

Database & Machine

Knowledge base Learning
Technology

agents structured
objects programming
= = 1974
1998 1982
 So, what’s a software agent?
• No consensus yet, but several key properties are
important to this emerging paradigm. Agents are:
– Autonomous, taking the initiative as appropriate
– Goal-directed, maintaining an agenda of goals which it pursues
until accomplished or believed impossible.
– Taskable: one agent can delegate rights/actions to another.
– Situated in an environment (computational and/or physical) which
it is aware of and reacts to.
– Cooperative with other agents (software or human) to
accomplish its tasks.
– Communicative with other agents (human
or software)
– Adaptive, modifying beliefs &
behavior based on experience
 Some key ideas
• Software agents offer a new paradigm for very large scale
distributed heterogeneous applications.
• The paradigm focuses on the interactions of autonomous,
cooperating processes which can adapt to humans and
other agents.
• Mobility is an orthogonal characteristic which many, but
not all, consider central.
• Intelligence is always a desirable characteristic but is not
required by the paradigm.
• The paradigm is still forming.
 Why is communication
important?
• Most, but not all, would agree that
communication is a requirement for cooperation.
• Societies can do things that no individual (agent)
can.
• Diversity introduces heterogeneity.
• Autonomy encourages disregard for other
agents’ internal structure.
• Communicating agents need only care about
understanding a “common language”.
 What is communication?
• Communication almost always means “communication in
a common language”
• “Language” does not include natural languages only.
• Understanding a “common language” means:
– understanding of its vocabulary, i.e., understanding of the
meaning of its tokens
– knowing how to effectively use the vocabulary to perform tasks,
achieve goals, effect one’s environment, etc.
• For software agents, an Agent Communication Language
(ACL) is primarily concerned with the vocabulary
 Some ACLs
•Is CORBA an ACL?
•Knowledge sharing approach
– KQML, KIF, Ontologies
•FIPA Shared
•Ad hock languages ? experiences
and strategies
– e.g., SGI’s OAA
e.g., ?
Intentional Shared beliefs, plans, goals,
Sharing
and intentions
e.g., KQML, FIPA,
KIF, Aglets
Knowledge Shared facts, rules, constraints,
Sharing
procedures and knowledge

Object
e.g., CORBA, Sharing
Shared objects, procedure calls
RPC, RMI and data structures
 Agent Communication,
at the technical level
• Messages are transported using some lower-level
transport protocol (SMTP,TCP/IP, HTTP, IIOP, etc.)
• An Agent Communication Language (ACL) defines the
types of messages (and their meaning) that agents may
exchange.
• Over time, agents engage in “conversations.” Such
interaction protocols (negotiation, auction, etc.), defines
task-oriented, shared sequences of messages.
• Some higher-level conceptualization of an agent’s goals
and strategies drives the agent’s communicative (and
non-communicative) behavior.
 What Comes Next
• Conceptual and theoretical foundations I
– The layered nature of communication, services, mobility issues,
Speech Act Theory, BDI
– Knowledge Representation and Ontology Issues
• The Knowledge Sharing Effort
– KIF, KQML, Ontolingua
• The Foundation for Intelligent Physical Agents
– FIPA ACL, FIPA Agent Platform
• Semantic accounts for ACLs
• Alternative approaches and languages
• APIs, Systems and Applications
• Trends and future directions
• Conclusions
 Conceptual
and
Theoretical
Foundations
 Historical Note:
Knowledge Sharing Effort
• Initiated by DARPA circa 1990
• Sponsored by DARPA, NSF, AFOSR, etc.
• Participation by dozens of researchers in
academia and industry.
• Developing techniques, methodologies and
software tools for knowledge sharing and
knowledge reuse.
• Sharing and reuse can occur at design,
implementation or execution time.
 Knowledge Sharing Effort
• Knowledge sharing requires a communication
which requires a common language
• We can divide a language into syntax, semantics,
and pragmatics
• Some existing components that can be used
independently or together:
– KIF - knowledge Interchange Format (syntax)
Propositional
– Ontolingua - a language for defining sharable
ontologies (semantics)
– KQML - a high-level interaction
language (pragmatics) Propositional
attitudes
 Knowledge Interchange Format
Sys 3 Know. Base
in
Know. Base
Lang3 in KIF

KIF <-> Lang3 Translator Library

• KIF ~ First order logic
KIF
with set theory KIF <-> Lang1 Translator KIF <-> Lang2 Translator

• An interlingua for encoded Know. Base Know. Base

declarative knowledge in
Lang1 Sys 1
in
Lang2
Sys 2
– Takes translation among n
systems from O(n2) to O(n)
• Common language for reusable knowledge
– Implementation independent semantics
– Highly expressive - can represent knowledge in typical application
KBs.
– Translatable - into and out of typical application languages
– Human readable - good for publishing reference models and
ontologies.
• Current specification at http://logic.stanford.edu/
 Common Semantics
Shared Ontologies and Ontolingua
• Ontology: A common vocabulary and agreed
upon meanings to describe a subject domain.
• Ontolingua is a language for building, publishing,
and sharing ontologies.
– A web-based interface to a browser/editor
server.
– Ontologies can be automatically translated into
other content languages, including KIF, LOOM,
Prolog, etc.
– The language includes primitives for combining
ontologies.
 Common Pragmatics
Knowledge Query and Manipulation
Language
• KQML is a high-level, message-oriented,
communication language and protocol for information
exchange independent of content syntax and ontology.
• KQML is also independent of
– transport mechanism, e.g., tcp/ip, email, corba,
IIOP, ...
– High level protocols, e.g., Contract Net, Auctions, …
• Each KQML message represents a single speech act
(e.g., ask, tell, achieve, …) with an associated
semantics and protocol.
• KQML includes primitive message types of particular
interest to building interesting agent architectures (e.g.,
for mediators, sharing intentions, etc.)
 Common High-level Protocols
• There is also a need for communication agents to agree
on the agent-level protocols they will use.
• The protocol is often conveyed via an extra parameter
on a message
– (ask :from Alice :to Bob … :protocol auction42 …)
• Common protocols:
– Contract net
– Various auction protocols
– Name registration
• These protocols are often defined in terms of constraints
on possible conversations and can be expressed as
– Grammars (e.g., DFAs, ATNs, …)
– Petri networks
– Conversation plans
– Rules or axioms
Common Service Infrastructure
• Many agent systems assume a common set of services
such as:
– Agent Name Sever
– Broker or Facilitator
– Communication visualizer
– Certificate server
• These are often tied rather closely to an ACL since a
given service is implemented to speak a single ACL
• Moreover, some of the services (e.g., name registration)
may be logically ACL-dependent
– e.g., Some ACLs don’t have a notion of an agent’s name and
others have elaborate systems of naming
 Speech Act
Theory and BDI
Theories
 The intentional level, BDI theories,
speech acts and ACLs: How do they all
fit together?
• ACL have message types that are usually
modeled after speech acts
• Speech acts may be understood in terms of
an intentional-level description of an agent
• An intentional description makes references to
beliefs, desires, intentions and other
modalities
• BDI frameworks have the power to describe
an agents’ behavior, including communicative
behavior
 The intentional stance
• Agents have “propositional attitudes”
• Propositional attitudes are three-part
relationship between
– an agent,
– a content-bearing proposition (e.g., “it is
raining”), and
– a finite set of propositional attitudes an
agent might have with respect to the
proposition (e.g., believing, asserting,
fearing, wondering, hoping, etc.)
• <a, fear, raining(tnow) >
 On ascribing mental
qualities to machines
• The issue is not whether a system is really
intentional but whether we can coherently
view it as such (Daniel Dennett)
• Ascribing mental qualities to machines (John
McCarthy):
– legitimacy: the ascription expresses the same
information about a machine that it expresses about
a person
– usefulness: the ascription helps us understand the
structure of the machine, its past or future behavior,
or how to repair it or improve it.
 BDI Agents, Theories and
Architectures
• BDI architectures describe the internal state of
an agent by the mental states of beliefs, goals
and intentions
• BDI theories provide a conceptual model of
the knowledge, goals, and commitments of an
agent
• BDI agents have some (implicit or explicit)
representations of the corresponding attitudes
BDI Model and Communication

B + D => I B + D => I
I => A I => A

• Communication is a means to (1) reveal to others what our

BDI state is and (2) attempt to effect the BDI state of others.
• Note the recursion: an agent has beliefs about the world,
beliefs about other agents, beliefs about the beliefs of other
agents, beliefs about the beliefs another agent has about it, ...
 Criticism of BDI theories
• The necessity of having all three modalities is
questioned from both ends:
– too few
– too many
• System builders question their relevance in
practice:
– multi-modal BDI logics do not have complete
axiomatizations
– they are not efficiently computable
There is a gap between theory and practice
 Speech Act Theory

High level framework to account for human

communication
Language as Action (Austin)

• Speakers do not just utter true or false

sentences
• Speakers perform speech acts:
requests, suggestions, promises, threats,
etc.
• Every utterance is a speech act
Speech Act Theory (continued)

Example: “Shut the door !”

• locution
physical utterance with context and reference, i.e.,
who is the speaker and the hearer, which door etc.
• illocution
the act of conveying intentions, i.e., speaker wants
the hearer to close the door
• perlocutions
actions that occur as a result of the illocution, i.e.,
hearer closes the door
 Conceptual
and Theoretical
Foundations II
 Representation and Reasoning
• Intelligent agents need to be able to represent and
reason about many things, including:
– models of other agents (human or artificial) beliefs, desires,
intentions, perceptions, plans, etc.
– task, task structures, plans, etc.
– meta-data about documents and collections of documents
• In general, they will need to communicate the same
range of knowledge.
• A variety of content languages have been used with
ACLs, including KIF, SL, Loom, Prolog, CLIPS, SQL, …
• There is a special interest in content languages that can
serve as a neutral, but expressive, interlingua for a
wide range of systems.
• We’ll look at KIF in a bit more detail.
 KR Language Components
•A logical formalism
–Syntax for well formed formulae (wffs)
–Vocabulary of logical symbols (e.g., and, or, not, =>, ...)
–Interpretation semantics for the logical symbols, e.g.,
“(=> A B)” is true if and only if B is true or A is false.
•An ontology
–Vocabulary of non-logical symbols (relations,functions,constants)
–Definitions of non-primitive symbols, e.g.
(<=> (Bachelor ?x) (AND (Man ?x) (Unmarried ?x)))
–Axioms restricting the interpretations of primitive symbols, e.g.
(=> (Person ?x) (Gender (Mother ?x) Female))
•A proof theory
–Specification of the reasoning steps that are logically sound, e.g.
From “(=> S1 S2)” and “S1”, conclude “S2”
 O-O Languages Too Restrictive
• Frames, object schema, description logics are
popular KR languages used for ontologies
• They support definitional axioms of the form:
– R(x)  …  P(x)  … {subclass}
– R(x)  …  [S(x,y)  P(y)]  … {value class}
– R(x) … y S(x,y)  … {value cardinality}
…
• They don’t support –
– N-ary relations and functions
– Standard properties of relations and functions
E.g., transitive, symmetric
– Partial sufficient conditions
E.g., x>0  R(x)
 Other alternatives

• OKBC (see ontologies)

• Java objects (see AgentBuilder)
• SL (see FIPA)
• Constraints
• Database tuples
• RDF
• ..your favorite representation language here..
Ontologies
 Common Semantics
Shared Ontologies and Ontolingua

Ontology : A common vocabulary and agreed upon

meanings to describe a subject domain.
On*tol"o*gy (?), n. [Gr. the things which exist (pl.neut. of , , being,
p.pr. of to be) + -logy: cf.F. ontologie.]
That department of the science of metaphysics which
investigates and explains the nature and essential properties
and relations of all beings, as such, or the principles and
causes of being.
Webster's Revised Unabridged Dictionary (G & C. Merriam Co., 1913, edited by Noah Porter)

This is not a profoundly new idea …

–Vocabulary specification
–Domain theory
–Conceptual schema (for a data base)
–Class-subclass taxonomy
–Object schema
 Conceptual Schemas
A conceptual schema specifies the intended meaning
of concepts used in a data base
139
Data 74.50
Base: 140
77.60
… …
Data Base Table: price
*stockNo: integer; cost:
Schema: float
Auto
Product
Ontology
price(x, y) =>
 (x’, y’) [auto_part(x’) Product
Conceptual & part_no(x’) = x Ontology

Schema: & retail_price(x’, y’, Value-Inc)

& magnitude(y’, US_dollars) = y]

Units &
Measures
Ontology
Implicit vs. Explicit Ontologies

• Systems which communicate and work

together must share an ontology.
• The shared ontology can be implicit or
explicit.
• Implicit ontology are typically represented only
by procedures
• Explicit ontologies are (ideally) given a
declarative representation in a well defined
knowledge representation language.
 Conceptualizations, Vocabularies
and Axiomitization

• Three important aspects to explicit ontologies

– Conceptualization involves the underlying model of the
domain in terms of objects, attributes and relations.
– Vocabulary involves assigning symbols or terms to refer to
those objects, attributes and relations.
– Axiomitization involves encoding rules and constraints which
capture significant aspects of the domain model.
• Two ontologies may
– be based on different conceptualizations
– be based on the same conceptualization but use different
vocabularies
– differ in how much they attempt to axiomitize the ontologies
 Simple examples

fruit fruit

apple lemon orange pomme citron orange

fruit
fruit
apple citrus pear
tropical temperate
lime lemon orange
 Knowledge
Sharing Effort
(KSE)
 Knowledge
Interchange
Format (KIF)
 KIF Syntax and Semantics
• Extended version of first order predicate logic
• Simple list-based linear ASCII syntax, e.g.,
(forall ?x (=> (P ?x) (Q ?x)))
(exisits ?person (mother mary ?person))
(=> (apple ?x) (red ?x))
(<<= (father ?x ?y) (and (child ?x ?y) (male ?x))
• Model-theoretic semantics
• KIF includes an axiomatic specification of large
function and relation vocabulary and a vocabulary
for numbers, sets, and lists
 Big KIF and Little KIF
• That KIF is highly expressive language is a
desirable feature; but there are disadvantages.
– complicates job of building fully conforming systems.
– resulting systems tend to be “heavyweight”
• KIF has “conformance categories” representing
dimensions of conformance and specifying
alternatives within that dimension.
• A “conformance profile” is a selection of
alternatives from each conformance category.
• System builders decide upon and adhere to a
conformance profile sensible for their applications.
 KIF Summary
• KIF is the only widely used interlingua for KB systems
– KIF is the focus of an ANSI standardization effort
– See KIF spec at <http://logic.stanford.edu/> and also
<http://www.cs.umbc.edu/kif> for more information.
• Its future outside the AI-related community is unclear
– It may not be acceptable to a wider community because its too
logic-oriented or not object-oriented or …
– Then again, it’s expressive power may win the day!
• Defining a mapping of KIF to XML might make it more
acceptable.
 Knowledge
Query and
Manipulation
Language
(KQML)
 KQML
Knowledge Query and Manipulation
Language
• KQML is a high-level, message-oriented, communication
language and protocol for information exchange
independent of content syntax and ontology.
• KQML is independent of
– the transport mechanism (e.g., tcp/ip, email, corba objects, IIOP,
etc.)
– Independent of content language (e.g., KIF, SQL, STEP, Prolog,
etc.)
– Independent of the ontology assumed by the content.
• KQML includes primitive message types of particular
interest to building interesting agent architectures (e.g.,
for mediators, sharing intentions, etc.)
 KQML Specifications
• There are two KQML specification documents:
– Specification of the KQML Agent-Communication Language plus
example agent policies and architectures, The DARPA Knowledge
Sharing Initiative, External Interfaces Working Group, 1993.
http://www.cs.umbc.edu/papers/kqml93.pdf
– A Proposal for a new KQML Specification, Yannis Labrou and Tim
Finin, TR CS-97-03, Feb.1997, Computer Science and Electrical
Engineering Department, University of Maryland Baltimore
County, Baltimore, MD 21250.
http://www.cs.umbc.edu/kqml/papers/kqml97.pdf
• There are also many dialects and “extended” versions of
KQML plus lots of important concepts not addressed in
either specification document (e.g., security).
• We’ll mostly focus on the 1997 document plus other ideas
used in practice.
 Multiple KQML dialects

1997
1997 1993
Spec
Spec
1993 Dialect
Dialect
Spec
Spec
Dialect
Dialect
Notional
KQML

ACLs
 A KQML Message
(tell :sender bhkAgent
performative :receiver fininBot
:in-reply-to id7.24.97.45391
parameter :ontology ecbk12
value :language Prolog
:content
“price(ISBN3429459,24.95)”)
Represents a single speech act or performative
ask, tell, reply, subscribe, achieve, monitor, ...
with an associated semantics and protocol
tell( i,j, Bi ) = fp[Bi Bi   Bi( Bifj Bi  Uifj Bi )]  re[Bj Bi] ...

and a list of attribute/value pairs

:content, :language, :from, :in-reply-to
 KQML Syntax
• KQML was originally defined as a language with a
particular linear syntax which is based on Lisp.
• Alternate syntaxes have been used, e.g., based on
SMTP, MIME, HTTP, etc.)
– There are proposals for a meta-syntax that can support
different syntactic dialects.
• KQML has also been mapped onto objects and
passed from agent to agent as objects (e.g., if in the
same memory space) or serialized objects.
• KQML is not about syntax.
 Performatives (1997)
Insert
Tell
Uninsert Inform Untell
Delete-one
Delete-all DB Basic Broadcast
Undelete Forward
Ask-if Inform
Ask-one Network
Ask-all Basic Achieve
Unachieve

StreamStream Query Request Goal

Eos
KQML
Performatives Facilitation
Cursor
Standby Broker-one
Ready Recommend-one
Next Reply Recruit-one
Rest Stream
Promise Broker-all
Discard Eos Recommend-all
Advertise
Deny Unadvertise Recruit-all
Meta
Subscribe
 Simple Query Performatives
ask-if(P)
ask-one(P)

tell(P) Sorry

A tell((p1 p2 p3...)) B A B
tell(P1)
tell(P2)

ask-all(P) tell(P3)
eos

Stream-all(P)

• The ask-one, ask-all, ask-if, and stream-all

performatives provide a basic query mechanism.
 Active Information
Performatives
Subscribe(ask(p))
A B
tell(p), tell(p’),...

• The subscribe performatives is used to request active

information services.
• subscribe(P) means roughly “Keep your response to P
current”
• Note that it’s content is an embedded KQML performative
and thus it’s :language is KQML
 Facilitation Services
Facilitators are a class of agents who
• traffic in meta-knowledge about other agents.
• provide communication services such as:
– message forwarding and broadcasting
– resource discovery
– matchmaking
– content-based routing
– meta-knowledge queries
• Performatives of special interest to facilitators are
– advertise, broker, recruit, recommend, forward, broadcast, etc.
• Brokers are generally considered to focus on matchmaking
• Facilitators can be intelligent or not
– Intelligent facilitators use domain knowledge in matching services
needs and offers.
 Capability Description

advertise(q3)
advertise(q2)
ask-all(advertise(P) advertise(q1)

A
C FAC B
advertise(p1)
advertise(p2)

The advertise performative is used to describe

the performatives an agent is prepared to accept.
 Facilitation Performatives
The three facilitation broker(ask(P)) advertise(ask(P))

performatives come in a X-one

and X-all versions: A B ask(P) C
• Broker-one and broker-all
Broker tell(P) tell(P)

• Recruit-one and recruit-all

• recommend-one and recommend-all

recruit(ask(P)) advertise(ask(P)) recommend(ask(P)) adv(ask(P))

A B ask(P) C A B C
fwd(adv(ask(P)))
tell(P) ask(P)

Recommendtell(P)
Recruit
 Agent Names
• System for mapping agents into names is important in
most ACLs
• KQML assumes that names are local
– A can register with B under the name Alice
– A can register with C under the name Albert
• Doesn’t preclude the use of a central Agent Name
Server, an architecture used by most systems
• What gets registered under a name? Contact
information like:
name(albert, tcpip, [cujo.cs.umbc.edu,8080]).
Name(albert,smtp,[[email protected])
name(albert,http,[www.agents.umbc.edu:8090/kqml/albert])
 KQML Semantics
• Myth: KQML doesn’t have a good semantic
description.
• Reality: This was true for the first few years of its use,
but has not been true since 1994.
• Yannis Labrou defined a semantics in
– Yannis Labrou and Tim Finin, A semantics approach for KQML -- a
general purpose communication language for software agents, Third
International Conference on Information and Knowledge
Management (CIKM'94), Nov. 1994.
– Yannis Labrou, Semantics for an Agent Communication Language,
Ph.D. Thesis, UMBC, 1996.
– Yannis Labrou and Tim Finin, Semantics and Conversations for an
Agent Communication Language, in "Readings in Agents", Michael
Huhns and Munindar Singh (editors.), Morgan Kaufmann, 1997.
(reprint of IJCAI-97 paper).
• Other approaches to defining the semantics have
been partially explored (more on this later).
KQML APIs and System Interfaces

• There have been dozens of APIs written for KQML

• Written in and for different languages
– Lisp, Scheme, Prolog, C/C++, Java, CLIPS,
Smalltalk, Tcl, Perl, ...
• And interfacing to may different systems
– Loom, Cyc, SIMS (Information Integration), SIPE (Planning),
Various Databases, …
• More recent is the appearance of KQML-speaking
“agent shells”, offering more than just an API.
• More on these later
 For More Information
• Mailing lists
– [email protected]
– send email to [email protected] with
body text “info kqml” for more information
• Information server
– http://www.cs.umbc.edu/kqml/
• Specification documents
– 1993: http://www.cs.umbc.edu/kqml/kqml93.pdf
– 1996: http://www.cs.umbc.edu/kqml/kqml97.pdf
Ontolingua
 Ontolingua - Language
• Ontolingua allows full KIF
– 1st order logic with relation
constants in domain of discourse
– Extremely expressive
– Too much for most users
– Too much for most systems!
• Ontolingua provides an object-
oriented projection
• Statements within the o-o
sublanguage easy to make
– But any statement is allowed
• Ontolingua separates
representation from presentation
FIPA
 What is FIPA
• The Foundation for Intelligent Physical Agents
(FIPA) is a non-profit association.
• FIPA’s purpose is to promote the success of
emerging agent-based applications, services
and equipment.
• FIPA’s goal is pursued by making available in
a timely manner, internationally agreed
specifications that maximise interoperability
across agent-based applications, services and
equipment.
• http://www.fipa.org/
 Who is FIPA
• FIPA operates through the open international
collaboration of member organisations, which are
companies and universities active in the agent field.
• Companies: Alcatel, Boeing, British Telecom,
Deutsche Telekom, France Telecom, Fujitsu, Hitatchi,
HP, IBM, Fujitsu, Hewlett Packard, IBM, Intel, Lucent,
NEC, NHK, NTT, Nortel, Siemens, SUN, Telia,
Toshiba, etc.
• Universities and Research Institutes: GMD, EPFL,
Imperial, IRST, etc.
• Government Agencies: DARPA
 The
FIPA ACL
 TC2: Agent Communication
Language
• Called FIPA ACL
• Based on speech acts
• Messages are actions (communicative actions or CAs)
• Communicative acts are described in both a narrative
form and a formal semantics based on modal logic
• Syntax is similar to KQML
• Specification provides a normative description of high-
level interaction protocols (aka conversations)
 Agent-Standardization - FIPA
Cooperation between Agents
CAs for Information Exchange
• proposition or reference as content
• Basic CAs:
– inform
– query-ref
– not-understood
• Advanced CAs:
– inform-if, inform-ref
– confirm, disconfirm
– subscribe
 Agent-Standardization - FIPA
Cooperation between Agents
CAs for task delegation
• action-description as content
• Basic CAs:
– request
– agree
– refuse
– failure
– not-understood
• Advanced CAs:
– request-when, request-whenever
– cancel
 Agent-Standardization - FIPA
Cooperation between Agents
CAs for Negotiation
• action-description and proposition as content
• Initiating CA
– cfp
• Negotiating CA
– propose
• Closing CAs
– accept-proposal
– reject-proposal
 Agent-Standardization - FIPA
Cooperation between Agents
Example
(request
:sender (:name [email protected]:3410)
:receiver (:name hilton_hotel@tcp://hilton.com:5001)
:ontology fipa-pta
:language SL
:protocol fipa-request
:content
( action hilton_hotel@tcp://hilton.com:5001
( book-hotel (:arrival 04/07/1999) (:departure 12/07/1999)
(:infos ( ))
)))

FIPA 99: other possibilities to define content!

 Agent-Standardization - FIPA
Cooperation between Agents
FIPA Cooperation
• CAs have their own formal semantics
– difficult to implement
– need not be implemented - agent must behave
according to semantics
• Interaction protocols define structured
conversations
– based on CAs
– basis for dialogues between agents
– basic set of pre-defined IPs
– own IPs can be defined
 Agent-Standardization - FIPA
Cooperation between Agents
FIPA-Query (simplified - for information
exchange)

query

not-understood inform
 Agent-Standardization - FIPA
Cooperation between Agents
FIPA-Request - for task delegation

request(action)

not-understood refuse(reason) agree

failure(reason) inform(done()) inform-ref

 Agent-Standardization - FIPA
Cooperation between Agents
FIPA-Contract Net - for negotiation
cfp(action, pre1)

not-understood refuse(reason) propose(pre2)

Deadline

reject-proposal accept-proposal

failure(reason) inform(done) cancel

 The
FIPA Agent
Platform
 FIPA Agent Platform

Agents belong to one or more

agent platforms which provide
basic services.
software AA

AMS DF ACC
IIOP

internal platform message transport

 FIPA Agent Platform
The AMS (Agent Management
System) provides services like
lifecycle management (creation,
deletion, pausing, …), name
software AA registration, name lookup, and
authentication.

AMS DF ACC
IIOP

internal platform message transport

 FIPA Agent Platform
The DF (Directory Facilitator) provides
yellow pages services which describe
the attributes and capabilities of
agents in the platform.
software AA

AMS DF ACC
IIOP

internal platform message transport

 FIPA Agent Platform
The ACC (Agent
Communication Channel)
accepts and delivers message
between agents on different
software AA platforms (+store and forward,
+firewalls)

AMS DF ACC
IIOP

internal platform message transport

FIPA Platform Implementations

• Several platforms have been implemented

– Zeus (BT)
– Mecca (Siemens)
– Spawar
– JADE (Cselt)
– Nortel
– Comtec
and interoperability has been demonstrated.
 ACL
Semantics
 Outline

• Cohen & Levesque

–Theory of Rational Agency
–Cohen & Levesque on ACL Semantics
• KQML Semantics (Labrou)
• FIPA ACL Semantics
• Comparing ACL semantics approaches
& Comments
Cohen &
Levesque
Rational
Agency
 The Cohen & Levesque
Approach

• Most attempts for semantics for ACL descend

from the work of Cohen & Levesque (C&L)
• Intention = Choice + Commitment
• Integration of Agent Theory and Semantics of
Communication Primitives
• A (partial) theory of rational agency
• Possible-worlds semantics
 Commitments and Intentions
• Internal Commitment:
– (P-GOAL x p q) =
(1) (BEL x p) 
(2) (GOAL x (LATER p)) 
(3) [KNOW x (PRIOR [(BEL x p)  (BEL x p)  (BEL x q)]
 [GOAL x (LATER p)] )]
meaning
“(1) agent x believes p is currently false
(2) chooses that it be true later
(3) and x knows that before abandoning that choice, he
must either believe it is true, or that it will never be true,
or that some q (an escape clause) is false”
 What has just happened, i.e.,
x believes that a will happen

The p of P-GOAL Intention next and a did happen

• (INTEND x a q) =
(P-GOAL x [DONE x (BEL x (HAPPENS a))?;a] q)
– x has the persistent goal of reaching a state at which it believes
that a will happen, after which (state) a does happen
• Intending is a special kind of commitment
• The agent is committed to arriving at a state in which he is
about to do the intended action next
• Thus an agent cannot be committed to doing something
accidentally or unknowingly
• “I intend for the sun to rise tomorrow” vs
“I intend to get an “A” in this course”
 Thoughts on C &L Intention
• Just because an agent intends p, it does not mean
that the agent will even attempt to achieve p
– remember the “escape clause” in the P-GOAL definition
a “pessimistic” agent might drop all its goal because “the sky
is blue” or for any other reason
• The definition of intention does not guarantee a causal
relationship between the agent’s action and “an action
occurring”
– the agent is only required to reach a state that the agent
believes that will lead to “the action a occurring”
C& L on ACL
Semantics
 ACLs a la Cohen & Levesque

• C&L object to the use of “performative” to

describe KQML’s communication primitives
• Communicative acts (CAs) are attempts to
communicate
• C&L build on their earlier work on rational
agency to define CAs as attempts that involve
two (or more) rational agents (teams)
• Interesting work that focuses on defining rational
agents and describing team formation.
 Semantics for INFORM
Not present in
ATTEMPT def’n
• {INFORM speaker listener e p} =
The “honest effort”
{ATTEMPT speaker listener e
(know listener p)
[BMB listener speaker
(P-GOAL speaker (KNOW listener (KNOW speaker
P)))]}

• An INFORM is defined as an attempt in which to

make an “honest effort”, the speaker is committed
to making public that he is committed to the
listener’s knowing that he (the speaker) knows p.
 KQML
Semantics
 Which Agent States? (Labrou
1996)
• Preconditions indicate the necessary state for an
agent in order to send a performative and for the
receiver to accept it and successfully process it.
• Postconditions describe the states of both
interlocutors after the successful utterance of a
performative (by the sender) and after the receipt and
processing (but before a counter utterance) of a
message (by the receiver).
• Preconditions indicate what can be assumed to be the
state of the interlocutors involved in an exchange.
Similarly, the postconditions are taken to describe the
states of the interlocutors assuming the successful
performance of the communication primitive
 Semantics for TELL
TELL(A,B,X)
• A states to B that A believes X to be true (for A).
• bel(A,X)
• Pre(A): bel(A,X)  know(A,want(B,know(B,S)))
where S may be bel(B,X) or NOT(bel(B,X))
Pre(B): intend(B,know(B,S))
• Post(A): know(A,know(B,bel(A,X)))
Post(B): know(B,bel(A,X))
• Completion: know(B,bel(A,X))
• The completion condition and postconditions hold unless
a SORRY or ERROR suggests B’s inability to properly
acknowledge the TELL.
 Semantics for the proactive-
TELL
proactive-TELL(A,B,X)
• A states to B that A believes the content to be true.
• bel(A,X)
• Pre(A): bel(A,X)
Pre(B): NONE
• Post(A): know(A,know(B,bel(A,X)))
Post(B): know(B,bel(A,X))
• Completion: know(B,bel(A,X))
• The postconditions and completion condition hold
unless a SORRY or ERROR suggests B’s inability
to properly acknowledge the TELL.
FIPA ACL
Semantics
 TC2: Agent Communication
Language
• Called FIPA ACL
• Based on speech acts
• Messages are actions (communicative actions or CAs)
• Communicative acts are described in both a narrative
form and a formal semantics based on modal logic
• Syntax is similar to KQML
• Specification provides a normative description of high-
level interaction protocols (aka conversations)
Outline of FIPA ACL Semantics
• A primitive’s meaning is defined in terms of
FPs and REs
• The Feasibility Preconditions of a CA define
the conditions that ought to be true before an
agent may plan to execute the CA
• The Rational Effect is the effect that an agent
hopes to bring about by performing an action
(but with no guarantee that the effect will be
achieved)
• The FPs and the REs involve agents state
descriptions that are given in SL
 Semantic Language (SL)
• SL is the formal language used to define the
semantics of FIPA ACL
• In SL, logical propositions are expressed in a logic
of mental attitudes and actions
• The logical framework is a first order modal
language with identity (similar to Cohen &
Levesque)
• SL provides formalizations for three primitive
mental attitudes: Belief, Uncertainty and Choice
(or Goal); Intention is defined as a Persistent Goal
• SL can express propositions, objects and actions
 An example of FIPA ACL
semantics (inform)
<i, inform( j,  )>
FP: Bi   Bi( Bifj  Uifj)
RE: Bj

Agent i informs agent j that (it is true that) it is raining

today:
(inform
:sender i
:receiver j
:content "weather(today,raining)"
:language Prolog
:ontology weather42)
Another example of FIPA ACL
semantics (request)

<i, request( j, a )>

FP: FP(a) [i\j]  Bi Agent( j, a )  Bi Ij Done(a)
RE: Done(a)

Agent i requests j to open a file:

(request
:sender i
:receiver j
:content "open \"db.txt\" for input"
:language vb)
Evaluation of
ACLs and
Semantic
Approaches
 Different ACLs: different
semantic approaches
• Different approaches to the semantics of an
ACL
– KQML semantics (Labrou 1996)
– FIPA ACL (FIPA ACL specification)
– ACL semantics (Cohen & Levesque)
• KQML’s semantics (Labrou 1996)
• Comparison between KQML and FIPA ACL
(primarily based on their semantics)
• Cohen & Levesque points on ACLs
• Why not KQML+KIF for an ACL?
 Comparison of KQML tell and
FIPA ACL inform
• The difference is only observable in the semantics
• Syntactically the two messages are almost identical
• Both languages make the same basic assumption
of non-commitment to a content language (in this
performative)
• Semantically they differ at two levels:
– different ways to describe the primitive, i.e., pre-, post-,
completion conditions for KQML, FPs and REs for FIPA
ACL
– different language to describe the propositional (mental)
attitudes, e.g., KQML’s bel is not the same as FIPA ACL B
operator
 How close can a FIPA ACL
primitive get to KQML tell?
<i, KQML-like-tell( j, Bi )>
FP: Bi Bi   Bi( Bifj Bi  Uifj Bi )
RE: Bj Bi

which can be generated by replacing  by Bi in the

definition of inform:

<i, inform( j,  )>

FP: Bi   Bi( Bifj  Uifj)
RE: Bj
 How do KQML and FIPA ACL
differ?
• Different semantics; mapping of KQML
performatives to FIPA primitives and vice
versa is a futile exercise.
• Different treatment of the “administration
primitives”; in FIPA ACL register, unregister,
etc., are treated as requests for action with
reserved (natural language) meaning
• No “facilitation primitives”, e.g., broker,
recommend, recruit, etc., in FIPA ACL
• Reserved content language: a very murky
issue ...
 Which ACL should I use?
• Programmers do not care about semantics
and their details.
• As long as the agent does not implement
modalities (belief, intention, etc.) the semantic
differences are irrelevant to the developer.
• The similar syntax guarantees that a
developer will not have to alter the code that
receives, parses and sends messages.
• The code that processes the primitives should
change depending on whether the code
observes the proper semantics.
 Really ... which one is better?

• FIPA ACL is more powerful with composing

new primitives.
• The power stems from the power of the SL
language as a content language to describe
agents’ states.
• KQML’s weakness is its religious non-
commitment to a content language.
• Both have shortcomings; there are features
that developers would like to see in an ACL.
 Shortcomings of Current ACLs

• Intentional level description: which mental

attitudes, what definitions?
• Problems with mental attitudes: from theory to
practice
• Can all desirable communication primitives be
modeled after speech acts? Should they?
• Flexible description of agents’ capabilities and
advertising of such capabilities.
• How can we test an agent’s compliance with the
ACL?
• Ease of extending an ACL
Alternative
approaches
and
languages
 Alternatives to ACLs
• There are many alternatives to using ACLs for
communicating and sharing information.
• From oldest to newest...
– Natural language (Espanol)
– Database languages (SQL, …)
– Domain dependant (EDI, …)
– Distributed object systems (CORBA, ...)
– OKBC
– Service languages (e-speak, BizTalk, …)
– Web languages (XML, RDF, DAML)
• One size won’t fit all, so we need to appreciate the
strengths and weaknesses.
• We will also see mixing, matching and morphing
 Database Languages
• The database field has developed techniques for
sharing information in a distributed environment.
• In fact, it has pioneered the theory and practice of
critical concepts like:
– concurrency control
– transactions
– replication
– security and access control
– common query languages (e.g., SQL, OQL)
– common APIs (e.g., ODBC, JDBC)
some of which the agents world has mostly ignored to
date.
Domain Dependant Languages
• There have always been specialized languages,
protocols, architectures and systems developed for
sharing particular knowledge, e.g.:
– Electronic Data Interchange (EDI) -- designed for sharing well
defined business documents (PO, RFQ, …)
– Z39.50 -- designed to allow an IR client application to talk to
an IR backend server.
– Napster: designed for sharing MP3 files
 Domain Dependant Languages
Example -- EDI
• EDI involves the application to application exchange of
electronic data in support of standard business
transactions across enterprise boundaries in such a
way that no human interpretation or processing is
required.
• Two standards were developed in the 80’s: X12 in the
US and EDIFACT in the EU.
• These are designed to exchange such business
documents as purchase orders, requests for
quotations, etc. and their constituent parts.
• Oriented toward integration with legacy systems
• Now being reengineered for XML
• Not very general, expressive, flexible, or extensible
 Distributed Objects
• Approaches to sharing objects in a distributed system
have been evolving over the past 15 years.
• CORBA
• Distributed Computing Environment (DCE) developed
by the Open Group in the early 90’s
• Java
– RMI
– Enterprise Java Beans (EJB)
– Jini
• OLE/COM/DCOM/ActiveX (Microsoft)
• SOAP
 Distributed Objects -- Typical
Components
• A distributed object is an object that can be
accessed remotely. An object is typically
considered to encapsulate data and behavior.
• Remote procedure/method call
• Interface definition language by which one can
specify an object or class’s signature, I.e. its
methods and the number and types of their
arguments.
• ORB (Object request broker)
• Other standard services -- e.g., naming,
timing, security, persistence, etc.
 CORBA ORB
• Defined by the OMG (Object Management
Group) http://omg.org/
• See the CRRBA FAQ for more information
http://www.aurora-tech.com/corba-faq/ The
ORB is the heart of a CORBA system and
mediates communication between clients and
servers.
• Inter-orb communication is less standard.
• One can access remote objects by name, or
by interface or by capability.
• This last feature is provided by the CORBA
trader service
 Java

• Virtually all of what CORBA provides is also

available in Java via a combination of
– Java RMI
– Java RMI servers
– Beans and enterprise beans
– Jini
– Java event servers
– etc.
• Focusing on a single language has strong
advantages and disadvantages.
 Java Beans and EJBs
•http://java.sun.com/beans/
•JavaBeans components, or Beans, are reusable software
components that can be manipulated visually in a builder tool.
•Typical unifying features that distinguish a Bean are:
– Introspection: enables a builder tool to analyze how a Bean works
– Customization: enables a developer to use an app builder tool to
customize the appearance and behavior of a Bean
– Events: enables Beans to communicate and connect together
– Properties: enable developers to customize and program with Beans
– Persistence: enables developers to customize Beans in an app builder,
and then retrieve those Beans, with customized features intact, for future
use
•Enterprise JavaBeans (EJBs) extends the JavaBeans
component model to handle the needs of
transactional business applications.
 Jini
• Jini provides simple mechanisms which
enable devices to plug together to form
an impromptu community
• Each device provides services that other devices in the
community may use.
– These devices provide their own interfaces, which ensures
reliability and compatibility.
• Jini uses a lookup service with which devices and
services register.
• When a device plugs in, it goes through an add-in
protocol, called discovery and join-in.
– The device first locates the lookup service (discovery) and then
uploads an object that implements all of its services' interfaces
(join).
 Jini
• To use a service, a person or a program locates it using
the lookup service. The service's object is copied from the
lookup service to the requesting device where it will be
used.
• The lookup service acts as an temporary intermediary to
connect a client looking for a service with that service.
• Once the connection is made, the lookup service is not
involved in any of the resulting interactions between that
client and that service.
• Jini also defines a leasing and transaction mechanism to
provide resilience in a dynamic networked environment.
 Javaspaces
• JavaSpaces is a simple
unified mechanism for
dynamic communication,
coordination, and sharing
of objects between Java
technology-based network
resources like clients and
servers.
• It is based on the Linda
tuple-space model.

http://java.sun.com/products/javaspaces/
 Comparison of
DCOM/CORBA/Java
ORB Platform Applicable to Mechanism Implementations
Availability
COM/DCOM Originally PC "PC-centric" APIs to one
platforms, but distributed proprietary
Becoming systems system
available on other architecture
platforms

CORBA Platform- General Specification of many

independent and distributed distributed object
interoperability system technology
among platforms architecture
Java/RMI wherever Java General implementation of various
virtual machine distributed distributed
(VM) executes system object technology
architecture and
Web-based
Intranets
SEI ~1997
 SOAP: The Simple Object Access
Protocol
• SOAP is an XML/HTTP-based protocol for accessing services, objects
and servers in a platform-independent manner.
• The current IETF specification:
http://search.ietf.org/internet-drafts/draft-box-http-soap-01.txt
• The non-binary XML encoding provides flexibility and platform
independence
• The HTTP transport obviates many firewall problems.
• Offers several basic message oriented protocols, including
request-response and fire-and-forget.
• BizTalk builds on SOAP, adding more service oriented
features, such as QOS and routing information
 Open Knowledge Base
Connectivity
• http://ai.sri.com/~okbc/
• OKBC is to KBs what ODBC is to Databases -- defines a
standard API for frame-based KR systems
– Provides two access protocols (frame oriented operations and a
senential tell/ask) and a linear batch language (def-okbc)
– Supports a client-server model for interaction
– Provides an object-oriented view of a KRS
– Supports wide variation in underlying KRS
• Adopted as KRS interoperation protocol within DARPA
High Performance Knowledge Base (HPKB) program
– OKBC drivers available for Loom, Ontolingua, Ocelot, ATP,
JavaKB, TupleKB, ...
– OKBC applications include GKB (SRI), Jot (KSL), Ontolingua
(KSL), Riboweb (SMI), Protégé (SMI), Hike (SAIC), …
 Service Languages

• By service languages we mean a new class of

languages designed to facilitate service
description, service discovery, and application
data exchange.
• Examples include:
– toolTalk (DEC circa ‘96)
– e-speak (HP)
– BizTalk (Microsoft et. al.)
 HP E-Speak
• See Http://e-speak.org/
Community
• Defines a language and Broker of
protocols at the service layer Broker
Interest
• Initial software components
released under GPL E-Speak Component Bus
• Services: Broker, Discovery, Service Selection, Provisioning and Dispatch
Mediation, Composition Components
User Login, Billing,
• Specification: Contracts, Account Management, Authentication/Authorization,
Vocabularies, Services Matching & Lookup, Anonymity, ...

• Security: E-Speak core as a E-Speak Core

Discovery, Registration, Naming,
“sandbox”, local names, Security, Persistence, Messaging, Events,
certificates Vocabularies, Repository, ...

• XML, Java: queries, Transports, Platforms, Languages

HTTP, TCP/IP, ESIP, RMI, Jini, CORBA, DCOM, …
vocabularies, messaging COM+, EJB, Java, Perl, Python, ...
 Microsoft’s BizTalk
• See http://biztalk.org/
• BizTalk is an industry initiative started by
Microsoft and supported by a wide range of
organizations, from technology vendors like
SAP and CommerceOne to technology users
like Boeing and BP/Amoco.
• BizTalk Framework™ is a set of guidelines for
how to publish schemas in XML and how to
use XML messages to easily integrate
software programs together in order to build
rich new solutions.
 Web Languages
• As the web becomes increasingly pervasive
and important, it’s specialized languages for
representing and sharing information are
becoming more significant.
• Some key web languages
– HTML and web scraping
– XML and associated DTDs
– RDF and associated standards (e.g., RSS, PICS)
– More expressive web languages, such as SHOE
and DAML
 Conclusions

• One size won’t fit all

• General purpose vs. specialized languages
• Things will continue to evolve
• Advice: if you are implementing a single
application, before you go with an ACL,
convince yourself that it’s not right for either
(1) a database approach or (2) a distributed
objects approach
 APIs
and
Systems
 What kinds of applications
• Applications use KQML (or some other ACL),
they do not implement the ACL
• APIs facilitate the incorporation of KQML-
speaking capabilities into applications
• The ACL itself is an abstraction, a collection of
primitives that are deemed useful for higher level
communication between agents
• Existing applications have used KQML or ACL,
which is KQML with KIF as the content language
• There are no fielded applications that use the
FIPA ACL as of yet
 Applications and APIs to
examine
• Infosleuth (MCC)
• KaOS (Boeing)
• Infomaster (Stanford), uses ACL (KQML+KIF)
• Lockheed Martin
• JATLite (Stanford)
• JAFMAS (U of Cincinnati)
• Jackal (UMBC)
• JKQML (IBM)
• KQML-lite
• See appendix for still more...
 Some FIPA Platforms
• Mecca (Siemens)
• Jade (CSELT)
http://drogo.cselt.stet.it/ufv/jade/JADEFeatures.html
• FIPA-OS (Nortel)
• FIPA-Smart
http://dirac.nosc.mil:6996/FIPA_SMART/FipaSmartIntro.
html
• Zeus (BT)
http://www.labs.bt.com/projects/agents/zeus/
• CoABS (GITI)
Current Issues and
Future Trends
• Conversational policies
• ACLs and the web
 Conversations
• Conversations define allowed/useful/desirable
sequences of messages for particular tasks
and indicate where/how messages “fit” in
exchanges.
• Desiderata:
• Allow more intuitive and convenient method for
handling messages in context.
• Through conversation composition, scale to varying
levels of granularity.
• Provide conversation management independent of
agent implementation.
• Facilitate communication through conversation
sharing.
Addressing the shortcomings of the
semantics with conversations
• Both KQML and FIPA ACL include specifications
for conversations (or conversation protocols)
• Conversations are not part of the semantic
definition of the ACL
• Conversations shift the focus to an agent’s
observable behavior
• Programmers might find conversations more
useful than formal semantics
• The meaning of primitives is often
context/situation dependant and conversations
can accommodate context
 The Role of Conversation
Policies
• Modern ACLs are powerful enough to:
– Encompass several different ways to achieve the same goal
– Achieve several different goals with the same message
• If there was just one way to achieve any goal, CPs
would not be needed.
• Conversation Policies define conventional ways to
constrain the expressive power of an ACL
– Reduce the depth of modeling of other agents (and v.v.); and
publicly expose the agent’s goals.
– Reduce uncertainty about the next conversational move
• What kind of constraints have we developed?
Conversation Policies Also Regulate
Other Features of Agent
Communication
• Conversation management assumptions
– Exception handling
– Initiation, termination, interruption
– Concurrency and turn-taking
– Clarification, repair, insertion sequences
• Uptake acknowledgment assumptions
• Pragmatic principles
– Preferences on semantically equivalent messages
• Task-specific sequences with guaranteed properties
– Fairness
A Model of Agent Communication
ABSTRACT CONVERSATION POLICIES Termination Policies
Specific Goal
Achievement Policies
Exception Handling Synchrony Policies
Conversation
Policies
Management Policies
Sequence Policies Uptake Policies
Pragmatics Policies Other Policies

ABSTRACT COMPUTATIONAL MODELS

Other Process
Transition Net Models Models
(FTN, ATN, DFA, CPN) Entailment-based Models

AGENT IMPLEMENTATION AGENT IMPLEMENTATION

(e.g., Java) (e.g., Prolog)

MESSAGES ON THE WIRE

Parallel with computer mathematics

 Agents in Practice
• If agents are going to matter, they must be
easily integrated into standard computing
environments.
• This includes:
– Integrated into standard programming languages
– Able to interact with standard services (e.g. LDAP
servers)
– Easily integrated into applications that matter (e.g.,
SAP, MS Office apps, etc.)
– Able to work well on the web, in web browsers and
web servers
 Using XML to describe ACL
messages
• Both KQML and FIPA ACL are using a LISP-like
syntax to describe properly-formed ACL messages
• ACL messages have “deep” semantics (KR-like) than
account for the Communicative Act, the Sender and
the Receiver
• The deep semantics, in the case of FIPA ACL are
described in SL
• A ACL message as a syntactic object has parameters
that are not accounted for in the semantics (language,
ontology, in-reply-to, etc.)
 Using XML to describe ACL
messages (continued)
• Syntactically, ACL messages introduce
pragmatic elements and a particular syntax
useful for parsing and routing.
• The syntactic form (e.g., LISP-like) need not
be unique.
• Syntactically, ACL messages can be thought
as having an “abstract syntax”.
• The abstract syntax “allows” for multiple
syntactic representations or encodings
• Examples of encodings are: Lisp-like balanced
parenthesis list, XML or even a Java structure
 An example
<!DOCTYPE fipa_acl SYSTEM "fipa_acl.dtd">
<message>
<messagetype>
inform
</messagetype>
<messageparameter>
(inform <sender link="http://www.cs.umbc.edu/~jklabrou">
finin

:sender jklabrou
</sender>
</messageparameter>
<messageparameter>

:receiver finin <receiver link="http://www.cs.umbc.edu/~finin/">

finin
</receiver>
:content </messageparameter>
<messageparameter>

(CPU libretto50 <ontology link="http://www.cs.umbc.edu/~jklabrou/ontology/laptop.html">

laptop
</ontology>
pentium) </messageparameter>
<messageparameter>

:ontology laptop (CPU libretto50 pentium)

</content>
</messageparameter>
:language kif) <messageparameter>
<language link="http://www.stanford.edu/kif.html">
kif
</language>
</messageparameter>
</message>
 Comments on the XML-
encoding of ACL messages
• The content itself of the ACL message could
have been encoded in XML
• The “deep semantics” of the ACL message
are taken to be the same as before
(“canonical” syntactic encoding)
• The XML-encoding enhances the canonical
syntactic encoding:
– it contains parsing information
– parameter values are not strings but links
• The XML-encoding is not equivalent to the
canonical syntactic encoding
 Advantages of XML-encoding ACL
messages
• Parsing ACL messages is a big overhead of agent development.
• The XML encoding is easier to develop parsers for:
– one can use off-the-shelf XML parsers
– a modified DTD does not mean re-writing the parser
• ACL messages are more WWW-friendly
– easier integration with web-based technologies
– potential for taking advantages of WWW-solutions to outstanding ACL issues
(e.g., security)
• ACL messages introduce a pragmatics layer that is unaccounted at the
semantic level
• Using XML, helps better address these pragmatic aspects through the
use of links. Links point to additional information.
– links can assist with ontological problems (defining and sharing ontologies)
– links can point to agent capability and identity information, protocols, even
semantics.
 Beyond XML: RDF
• RDF (Resource Description Framework) is a W3C
metadata standard build on top of XML
(http://www.w3.org/RDF/)
• RDF data consists of nodes and attached attribute/value
pairs, providing the expressive power of semantic networks
– Nodes can be any web resources (pages, servers, basically anything for
which you can give a URI) including other RDF expressions.
– Attributes are named properties of the nodes, and their values are either
atomic (e.g., strings, numbers) or other resources or metadata instances.
• Other standards are built on top of RDF, including:
– P3P: Platform for Privacy Preference for the exchange of privacy
practices and preferences among Web sites, agents and users.
– PICS: an infrastructure for
associating metadata labels
with Internet content
Beyond RDF: SHOE and DAML
• RDF’s expressive power is quite limited, roughly
corresponding to that of semantic networks.
• SHOE is an HTML-based knowledge representation
language developed by Jim Hendler et al at the
University of Maryland
(http://www.cs.umd.edu/projects/plus/SHOE/)
• It provides
– an XML compliant way of encoding horn clauses and
embedding them in web pages
– a namespace for shared ontologies defined on other web pages
• Similar examples include Interlingua (Grosof et. al.) and
XML encodings of KIF.
• DAML (Darpa Agent Markup Language) will be the next
iteration of these ideas.
Conclusions
 Some key ideas
• Software agents offer a new paradigm for very large
scale distributed heterogeneous applications.
• The paradigm focuses on the interactions of
autonomous, cooperating processes which can adapt to
humans and other agents.
• Agent Communication Languages are a key enabling
technology
– Mobility is an orthogonal characteristic which many, but not all,
consider central.
– Intelligence is always a desirable characteristic but is not strictly
required by the paradigm.
• The paradigm is still forming and ACLs will continue to
evolve.
 Agent Communication
• Agent-agent communication is a key to
realizing the potential of the agent paradigm.
• Since interoperability is a defining
characteristic of agents, standards are
important!
• Candidates for standardization include
– Agent architecture
– Agent communication language
– Agent interaction protocols
– Agent knowledge
– Agent programming languages
• Standards will most develop through natural
selection, “nature red in tooth and claw”
 Agent Methodology
The KSE offers a four-part methodology for for
developing complex agent-based systems:
• Collect/construct necessary ontologies
• Use standard, published ontologies if possible
• Develop (and publish) new components as needed
• Use common tools, e.g. Ontolingua, GFP, ...
• Choose common representation language(s)
• e.g., SQL or KBMS with KIF is a recommended default
• Use an ACL like KQML as communication language
• extend with new performatives and protocols as needed
• Identify and define new higher-level protocols
• e.g., for negotiation, purchasing, cataloging, etc.
 What’s Needed Tomorrow
• Further develop semantics of ACLs
Common content languages and ontologies
A language for describing agent actions, beliefs, intentions, etc.
• Agent ontologies
Sharable ontologies for agent properties, behavior, etc
• Better handle on metadata
Abstractable and applicable to many content languages
• Declarative and learnable protocols
Languages for defining higher-level protocols based on more primitive ones
• Practical agent knowledge sharing
“Social” mechanisms for distributing information and knowledge
Viewing knowledge sharing as mobile declarative code?
• Frameworks for controlling collections of agents
E.g., artificial markets, natural selection, etc.
 For More Information
• General information on software agents
– http://agents.umbc.edu/
• The FIPA home
– http://www.fipa.org/
• Information on KQML, KIF, ontologies
– http://agents.umbc.edu/kqml
– http://agents.cs.umbc.edu/kif
– http://agents.umbc.edu/ontology/
• Information in Agent Communication
Languages
– http://agents.umbc.edu/acl/
Presenters
Yannis Labrou
http://www.cs.umbc.edu/~jklabrou
[email protected]

Dr. Yannis Labrou is a Visiting Assistant Professor at the Computer

Science and Electrical Engineering Department, University of Maryland,
Baltimore County (UMBC) and at the Institute for Global Electronic
Commerce (IGEC) at UMBC. He holds a PhD in Computer Science from
UMBC (1996) and a Diploma in Physics from the University of Athens,
Greece. Dr. Labrou's research focuses on software agents, an area in
which he has been actively involved for the past 8 years and Electronic
Commerce. Dr. Labrou is a founding member of the FIPA Academy and
has been an active participant in the development of the FIPA
specifications for software agents standards. He has served on a number
of conference organizing committees, program committees, and panels,
and has delivered invited tutorials and talks to conferences, research
labs and universities. He is the author of more than 30 publications in
research journals, books, and conferences. Prior to joining UMBC, Dr.
Labrou worked as an intern at the Intelligent Network Technology group
of the I.B.M. T.J. Watson Research Center.