=Paper=
{{Paper
|id=Vol-66/paper-5
|storemode=property
|title=Ontologies for interaction protocols
|pdfUrl=https://ceur-ws.org/Vol-66/oas02-16.pdf
|volume=Vol-66
|authors=Stephen Cranefield,Martin Purvis,Mariusz Nowostawski and Peter Hwang
}}
==Ontologies for interaction protocols==
https://ceur-ws.org/Vol-66/oas02-16.pdf
Ontologies for Interaction Protocols
Stephen Cranefield, Martin Purvis,
Mariusz Nowostawski and Peter Hwang
Department of Information Science
University of Otago
PO Box 56, Dunedin, New Zealand
scranefield@infoscience.otago.ac.nz
ABSTRACT be related to the future execution of the protocol, are traditionally
In this paper we propose reducing the degree of human interpre- either not represented explicitly (e.g. in an Agent UML sequence
tation currently necessary to understand an interaction protocol by diagram representation [17]) or are represented purely as labelled
describing at an abstract level the required agent actions that must ‘black boxes’ (e.g. in a Petri net representation [4]).
be ‘plugged into’ the protocol for it to be executed. In particular,
this can be done by designing and publishing ontologies describing In this paper we argue that the traditional models of interaction pro-
the input and output data that are processed during the protocol’s tocols are suitable only as specifications to guide human developers
execution together with the actions and decisions that the agents in their implementation of multi-agent systems, and even then often
must perform. An agent (or agent developer) that has previously contain a high degree of ambiguity in their intended interpretation.
defined mappings between the internal agent code and the actions Here we are not referring to the necessity for an interaction proto-
and decisions in an ontology would then be able to interpret any col to have formal semantics (although that is an important issue).
interaction protocol that is defined with reference to that ontology. Rather, we see a need for techniques that allow the designers of
The discussion is based on the use of Coloured Petri Nets to repre- interaction protocols to indicate their intentions unambiguously so
sent interaction protocols and the Unified Modeling Language for that a) other humans can interpret the protocols without confusion,
ontology modelling. and b) software agents can interpret protocols for the purposes of
generating conversations. Ideally, an agent would be able to down-
load an interaction protocol previously unknown to it, work out
1. INTRODUCTION where and how to plug in to the protocol its own code for message
Agent communication languages (ACLs) such as the Knowledge processing and for domain-specific decision making, and begin us-
Query and Manipulation Language (KQML) [7] and the Founda- ing that protocol to interact with other agents.
tion for Intelligent Physical Agents (FIPA) ACL [8] are based on
the concept of agents interacting with each other by exchanging We propose reducing the degree of human interpretation currently
messages that specify the desired ‘performative’ (inform, request, necessary to understand an interaction protocol by describing at an
etc.) and a declarative representation of the content of the mes- abstract level the required agent actions that must be ‘plugged into’
sage. Societies of agents cooperate to collectively perform tasks the protocol for it to be executed. In particular, this can be done by
by entering into conversations—sequences of messages that may designing and publishing ontologies describing the input and out-
be as simple as request/response pairs or may represent complex put data that are processed during the protocol’s execution together
negotiations. In order to allow agents to enter into these conversa- with the actions and decisions that the agents must perform. An
tions without having prior knowledge of the implementation details agent (or agent developer) that has previously defined mappings
of other agents, the concept of interaction protocols (also known between the internal agent code and the actions and decisions in an
as conversation policies) has emerged [11]. Interaction protocols ontology would then be able to interpret any interaction protocol
are descriptions of standard patterns of interaction between two or that is defined with reference to that ontology.
more agents. They constrain the possible sequences of messages
that can be sent amongst a set of agents to form a conversation of a For example, consider a protocol describing some style of auction.
particular type. An agent initiating a conversation with others can Inherent in this protocol are the concepts of a bid and response and
indicate the interaction protocol it wishes to follow, and the recip- the actions of evaluating a bid (with several possible outcomes).
ient (if it knows the protocol) then knows how the conversation is There are also some generic operations related to any interaction
expected to progress. A number of interaction protocols have been protocol such as the parsing of a message to check that it has a
defined, in particular as part of the FIPA standardisation process particular performative and that its content can be understood by
[9]. the agent in the current conversational context, and the creation of
a message.
The specification of the individual messages comprising an inter-
action protocol is necessarily very loose: usually only the message
performative, sender and receiver are described. This is because 2. EXAMPLE: THE FIPA REQUEST PRO-
an interaction protocol is a generic description of a pattern of in- TOCOL
teraction. The actual contents of messages will vary from one ex- Figure 1 shows the FIPA Request Protocol as defined in its current
ecution of the protocol to the next. Furthermore, the local actions experimental-status specification [10] using Agent UML (AUML)
performed and the decisions made by agents, although they may [17]. This protocol defines a simple interaction between two agents.
Receive request In Receive
Initiator, Participant,
answer request
request, refuse*, not-
result
understood*, agree, failure*, Agreed Agreed
inform-done : inform*, (processed)
FIPA-Request-Protocol inform-ref : inform* Request
Start sent
Process
Initiator Participant Refused precondition Result
Send Failed Done
Not
request
understood
request
Process
Out Process result
Process not understood Process
refusal failure Process
not-understood done
refuse
Figure 2: The Initiator role for the Request protocol as a CPN
x (outline only)
agree
Furthermore, the underlying intention of this protocol is not explic-
itly specified. In order to customise this protocol to a particular do-
failure main, a request initiator agent must ‘plug in’ domain-specific pro-
cedures at six different points: the handling of ,
and messages, analysing an message to
check if a precondition is specified by the participant, and the han-
inform-done x dling of the two different types of final response. Similarly, there
[agreed]
are (in one possible decomposition) three pieces of domain-specific
functionality that an agent wishing to play the role of participant
must supply: the recognition of the type of the request (correspond-
inform-ref ing to the two types of response and possibly resulting in a failure
to understand the message) and procedures for performing the two
different types of action that may be requested. We believe that an
interaction protocol is not completely specified until the interface
between the domain-specific agent-supplied code and the generic
Figure 1: The FIPA Request Protocol defined using AUML interaction protocol is defined. Clearly interaction protocols should
remain as generic as possible, making no commitment to any par-
ticular agent platform or implementation language. Thus the spec-
ification of this interface should be in terms of a programming-
One agent plays the Initiator role and sends a request for an action language independent representation. Furthermore, the agent op-
to be performed to another agent which plays the Participant role. erations related to a particular protocol will be related to the types
The protocol illustrates that there are three alternative responses of entity involved in the execution of that protocol, e.g. the notion
that the participant can make after receiving the request: it can of a bid in a ‘call for proposals’ protocol. This model of protocol-
refuse or agree to the request or it may signal that it did not un- related concepts and the operations that act on them is an ontology
derstand the request message. If it agreed, it subsequently sends that needs to be supplied along with the interaction protocol to give
a second response: a message indicating that its attempt to fulfil it a full specification.
the request action failed, a message signalling that the action has
been performed, or a message containing the result of performing
the requested action.
3. A COLOURED PETRI NET APPROACH
The above discussion was based on an analysis of an interaction
protocol expressed as an AUML sequence diagram. However, this
There are some aspects of this protocol that are not specified. The
form of diagram currently has some shortcomings for further in-
choice of whether the final response should be the message la-
vestigation of these ideas. First, AUML is currently underspecified
belled or the one labelled depends on
and the intended interpretation of an AUML sequence diagram is
the body of the original request (the latter choice only seems to be
not always clear. Second, the authors know of no tools that support
valid if the initiator requested an to be performed).
the use of AUML. Finally, AUML sequence diagrams do not have a
It is also not specified that each of the ,
way of explicitly modelling the internal actions of agents1 —which
and messages should contain the original request in their
are exactly the points of the protocol at which we wish to attach an-
content tuple along with an additional proposition (representing re-
notations refering to an ontology. We have therefore adopted an al-
spectively an error message, a precondition for the action to be per-
ternative modelling language for our research in this area: coloured
formed, and a reason for refusal). To make the specification more
Petri nets.
precise there needs to be a way of annotating the protocol with
constraints on the contents of and relationships between the mes- ½
AUML activity diagrams have this capability and can be used on
sages. These constraints would need to be expressed in terms of a their own or in conjunction with sequence diagrams to specify the
vocabulary relating to the structure of messages—i.e. an ontology internal agent processing [17]. However there are few examples of
for messages. their use for modelling agent interaction protocols.
Guard:
reply.inReplyTo->notEmpty() and
reply.inReplyTo = req.replyWith
Receive
request
answer In : FIPAMessage
req reply
Request sent :
FIPAMessage Agreed :
Pair
Refused : Not understood :
Pair Pair
Reason >
if reply.oclIsKindOf(FIPARefuseMessage)
then Bag{Pair.create(
req, Reason.createFromProposition(
reply.oclAsType(FIPARefuseMessage).reason))}
else Bag{}
endif
if reply.oclIsKindOf(FIPANotUnderstoodMessage)
then Bag{Pair.create(
req, Reason.createFromProposition(
reply.oclAsType(FIPANotUnderstoodMessage).reason))}
else Bag{}
endif
if reply.oclIsKindOf(FIPAAgreeMessage)
then Bag{Pair.create(
req, Precondition.createFromProposition(
reply.oclAsType(FIPAAgreeMessage).precondition))}
else Bag{}
endif
Figure 3: Details of the ‘Receive request answer’ transition
FIPAMessage
replyWith : String [0..1]
1 inReplyTo : String [0..1]
...
FIPARefuseMessage FIPANotUnderstoodMessage FIPAAgreeMessage ...
0..1 0..1 0..1 0..1 0..1 0..1
action reason
1 1
1 1 1 1
ActionDescription Proposition
action action reason precondition
1 1
0..1
CommunicativeActionDescription
0..1 0..1
Reason Precondition
«create» createFromProposition(p : Proposition) «create» createFromProposition(p : Proposition)
Figure 4: A partial ontology for the Request interaction protocol
Petri Nets [14] are a formalism and associated graphical notation separate CPN. Figure 2 shows an overview of the net for the Ini-
for modelling dynamic systems. The state of the system is repre- tiator role of the FIPA Request protocol (the ‘colours’ of places,
sented by places (denoted by hollow circles) that can contain tokens the arc inscriptions and the initial distribution of tokens are not
(denoted by symbols inside the places). The possible ways that the shown). In the figure, places are represented by circles and transi-
system can evolve are modelled by defining transitions that have tions are represented by squares. No tokens are shown. The places
input and output arcs (denoted by arrows) connected to places. The labelled In and Out are fusion places: they are shared between all
system dynamics can be enacted (non-deterministically) by deter- nets for the roles the agent can play (in any interaction protocol).
mining which transitions are enabled by the presence of tokens in The agent’s messaging system places tokens representing received
the input places, selecting one and firing it, which results in tokens messages in the In place and removes tokens from the Out place
being removed from its input places and new tokens being gener- (these represent outgoing messages) and sends the corresponding
ated and placed in the output places. messages.
Coloured Petri nets (CPNs) [12] are an elaboration of ordinary The fully detailed version of this Petri net encodes the following
Petri nets. In a coloured Petri net, each place is associated with process. The Initiator begins the conversation by sending a request
a ‘colour’, which is a type (although the theory of CPNs is inde- with its parameter set to a particular value. When an
pendent of the actual choice of type system). Places can contain a answer with a matching parameter value is received,
multiset of tokens of their declared type. Each input arc to a transi- the Receive request answer transition is enabled and can subse-
tion is annotated with an expression (possibly containing variables) quently fire at the agent’s discretion. This transition generates a
that represents a multiset of tokens. For a transition to be enabled, single token that is placed in one of the Agreed, Refused or Not
it must be possible to match the expression on each input arc to a understood places, depending on the communicative act of the re-
sub-multiset of the tokens in the associated input place. This may ply (the remaining two of these output places each receive an empty
involve binding variables. In addition, a Boolean expression asso- multiset of tokens). In the case that the other agent agreed to the
ciated with the transition (its guard) must evaluate to true, taking request, another message is subsequently expected from that agent
into account the variable bindings. When a transition is fired, the containing the result of the requested action. This is handled by the
matching tokens are removed from the input places and multiset right hand side of the net in a similar fashion.
expressions annotating the output arcs are evaluated to generate the
new tokens to be placed in the output places. If the expression on In this Petri net we have included transitions that correspond to in-
an output arc evaluates to the empty multiset then no tokens are ternal actions of the agent, such as those labelled Process refusal
placed in the connected place. and Process not understood. These are not part of the protocol
when it is viewed in the pure sense of simply being a definition of
The coloured Petri net formalism provides a powerful technique for the possible sequences of messages that can be exchanged. How-
defining system dynamics and has previously been proposed for use ever, we believe these communicate the underlying intent of the
in modelling interaction protocols [4]. In this paper we take a dif- protocol: there are a number of points at which the agent must in-
ferent approach from previous work (including our own [16, 15, voke particular types of computation to internalise and/or react to
18]) in the application of CPNs to interaction protocol modelling. the different states that can occur. In the example shown, most
We choose to model each side of the conversation (a role) using a of these ‘extra’ transitions occur after the final states of the pro-
tocol. However, this is not necessarily the case, e.g. the Process Refused : Pair
the precondition that may be specified by the other agent when it p
agrees to the request. This precondition must become true before
the other agent will fulfil the request (in the simple case it can just Process refusal
be the expression ). Although the Request protocol does not Guard: true
allow for any extra communication between the two agents regard- Operation: processRefusal(request: FIPARequestMessage,
ing this precondition, an agent might wish to do something out- reason: Reason)
side the scope of the conversation to help satisfy the precondition Inputs: { request = p.get(1), reason = p.get(2) }
(e.g. perform an action). Therefore, the initiator needs an opportu- Outputs: { }
nity to notice the precondition.
Figure 5: Details of the ‘process request refusal’ transition
Figure 3 shows the details of the Receive request answer tran-
sition. This is where we make the connection with ontologies: the «role»
types used as place colours and within arc expressions are concepts Initiator
in an associated ontology (a portion of which is shown in Figure 4). createPendingRequest() : FIPARequestMessage
processRefusal(req : FIPARequestMessage, rsn : Reason)
We use the object-oriented Unified Modeling Language (UML) [3] processRequestNotUnderstood(req : FIPARequestMessage, rsn : Reason)
to represent the ontology and UML’s associated Object Constraint processAgreementPrecondition(req : FIPARequestMessage, pre : Precondition)
Language (OCL) [19] as our expression language. For brevity, we processRequestedActionFailure(req : FIPARequestMessage, rsn : Reason)
processRequestDone(req : FIPARequestMessage)
adopt the convention that a variable appearing on an input arc processRequestResult(result : GroundTerm)
represents the singleton multiset ( is the OCL type cor-
responding to a multiset).
Figure 6: Specification of the Initiator role for the Request pro-
tocol
In the case of the Request protocol, the concepts that need to be
defined in the associated ontology are message types. Figure 4
therefore defines an inheritance hierarchy of FIPA ACL message agent are outside the scope of the Request protocol, in order for the
types2 (generalisation relationships are represented by arrows with protocol model to act as a stand-alone specification (without rely-
triangular heads, while associations are represented by arrows with ing on implicit assumptions about the meaning of certain places)
open heads). In addition, we have chosen to explicitly model the it should define the way in which the agent transfers information
concepts of a reason and a precondition that are associated with the from the Petri net to its own internal processes. To support this,
Request protocol. Within a FIPA ACL message these are both rep- we optionally associate an operation with each transition, specify-
resented as propositions, but here the and ing the inputs to the operation as OCL expressions and providing a
classes can be used (via their constructors) to achieve an additional list of variables to which the outputs should be assigned (note that
level of interpretation of a proposition. Note that although the on- UML allows multiple output parameters in an operation). Figure 5
tology is shown here as being a monolithic model, in practice some illustrates this for the Process request refusal transition.
of the classes shown would be imported from a separate UML pack-
age. The operations required to interface an agent with the CPN for a
given role constitute part of the ontology for the protocol. In this
In addition to the classes shown, the ontology is assumed to include section we describe two approaches for using UML to model the
a UML class template called . A class template is a class operations required for particular roles: a simple “static” approach
that is defined in terms of one or more other classes, which are and a more flexible but complex “dynamic” approach.
specified only as parameter names. When it is used (as in Figure 3)
specific types must be supplied to instantiate the parameters. 4.1 The Static Approach
represents a pair of elements with the type of each argument being
Figure 6 illustrates the static approach to including a role’s opera-
the corresponding supplied parameter.
tions in a UML ontology. This figure shows a class (annotated with
the role stereotype) representing the role and containing all re-
The arc expressions in Figure 3 use the operations
quired operations. Although this looks like the specification of an
and . These are predefined OCL operations used for
application programmer interface rather than an ontology, it is not
run-time type checking and type casting respectively.
intended that an agent must implement operations with the same
signatures as shown here. Instead an agent may be able to map
4. MODELLING INTERNAL AGENT OP- these operations into those it does possess. To do this, the role’s re-
quired operations would need to have some information about their
ERATIONS semantics specified, possibly using OCL pre- and postcondition ex-
In Figure 3, all processing represented by the transition is per-
pressions. This is a subject for future research.
formed by the guard and the output arc expressions. This is not
always the case. Consider the Process request refusal transition
The representation in Figure 6 does not model the operations re-
from Figure 2 (shown in detail in Figure 5). This represents the
quired for a given role as first class objects in UML, but as features
computation that an agent must do to react to the participant’s re-
of a class representing the role. Although this is a simple represen-
fusal of the request. Although any future actions of the initiator
tation, it has a number of shortcomings. Essentially it treats a role
¾ as an interface that an agent must implement if it wants to act in that
A more complex UML model for FIPA messages has been pre-
sented elsewhere [5], but that serves a different purpose. The model role. We call this the static approach because it doesn’t accommo-
in this paper is not intended as an update of that previous work, but date in a straightforward way the possibility of agents dynamically
instead provides a different view of FIPA message types. changing the roles they support. The UML object model does not
Agent Binding «powertype» ing a collection of objects, each being an instance
r: RoleType OpType of some class that implements an operation. These objects are in-
name: String
o: OpType
dexed by role and operation (this is shown using UML’s qualified
1 *
association notation). Roles and operations are both modelled as
1 0..1 «powertype» classes, so the types for these association qualifiers must be ‘pow-
RoleType
OpExecutor Object ertypes’ of and . A powertype is a class whose
instances are all the subclasses of another class [13, Chapter 23].
execute(b : Binding) : Binding
To invoke an operation, an agent calls on an
object. The arguments to this method must be completely generic,
* 1
before so a binding structure is provided as an argument. This maps the
«operation»
operation’s argument names to objects. The operation returns an-
Role Context
other binding list specifying values for the “result” parameter and
* * Operation
after
any output parameters.
* 1
: RoleType : OpType
5. CONCLUSION
In this paper we have identified two weaknesses in traditional mech-
Initiator
«operation» anisms for specifying agent interaction protocols: a lack of preci-
* * ProcessRefusal sion in defining the form of messages that are exchanged during the
0..1 0..1 protocol and the relationships between them, and the lack of any
{ in } req { in } reason
1 1
explicit indication of where and how the protocol interfaces with
an agent’s internal computation. We have proposed the use of an
FIPARequestMessage Reason
ontology associated with a protocol to define the relevant concepts
and the internal operations that an agent needs in order to partake
Figure 7: Specifying operations as first-class objects in a conversation using that protocol.
We note that some uses of interaction protocols are not concerned
allow classes (or agent types in this scenario) to change their set with the internal actions of agents, e.g. external monitoring of con-
of implemented interfaces at run time. Also, the notation does not versations for the purpose of compliance testing. For this type of
show graphically the relationships between the operations and the application it may be beneficial to provide a simpler view of proto-
ontological concepts on which they are dependent. cols that abstracts away the transitions representing internal actions
and we plan to investigate techniques for this.
4.2 The Dynamic Approach The discussion in this paper was based on a particular way of using
Figure 7 shows an alternative approach that addresses the concerns coloured Petri nets to model conversations. However, the princi-
raised above. The majority of the figure represents a base ontology ple applies to other approaches to specifying interaction protocols.
containing classes to which a specific role ontology would make In particular, we propose that AUML sequence and/or activity dia-
reference. Only the four classes at the bottom of the figure repre- grams should be extended to include the types of ontology-related
sent a specific ontology: a portion of the ontology for the Request annotation we have discussed.
protocol.
Two techniques were proposed for modelling the agent internal ac-
Modelling both entities and the operations that act on them as first tions necessary to use an interaction protocol: a static model and
class objects is difficult to do in a straightforward way without de- a dynamic model. We believe the dynamic model, although more
parting from a “strict metamodelling architecture” where there is complex, is more flexible and has more scope for adding seman-
a firm distinction between instances and classes [1]. In this case, tic annotations to define the operations—an extension necessary to
in order to define the types of operation arguments using associa- enable agents to deduce how to use their existing operations to im-
tions, each operation must be defined as a class. The abstract class plement those required by an interaction protocol.
represents the concept of an operation as being associ-
ated with a role and relating two contexts: the relevant local states The type of ontology discussed in this paper combines descriptions
of the world before and after the operation is performed. Particular of concepts and operations that act on them in a single model. To
operations are modelled as subclasses of with their in- date, there has been little work on the inclusion of actions in ontolo-
put and output arguments represented by associations labelled with gies, although methodologies for agent-oriented software engineer-
the ‘tagged values’ or (the stereotype operation special- ing typically include diagrams describing agent capabilities [2].
izes the notion of a class by allowing the use of these tagged val- In the knowledge acquisition research community there has been
ues). considerable study of techniques for building libraries of reusable
problem-solving methods, and work has been done on combining
If operations are classes, we need to consider what their instances such libraries and ontologies in a single system [6]. This research
are. The answer is that the instances represent snapshots of the may provide some insights into the problems of integrating action
operation’s execution in different contexts and with different argu- descriptions into ontologies.
ments, in the same way that a mathematical function can be re-
garded as the set of all the points on its graph. However, the oper- The aim of the work described in this paper is to reduce the degree
ation class only serves as a description of the operation: it will not of human interpretation required to understand an interaction proto-
be instantiated by an agent. Instead we model an agent as contain- col. The solution proposed here achieves this by including more de-
tailed information about the actions that participating agents must [11] M. Greaves, H. Holmback, and J. Bradshaw. What is a
perform. The use of an associated ontology provides terminology conversation policy? In F. Dignum and M. Greaves, editors,
for describing how the messages received and sent by agents are re- Issues in Agent Communication, volume 1916 of Lecture
lated to each other, and also allows signatures to be defined for the Notes in Artificial Intelligence, pages 118–131. Springer,
operations that agents must be able to perform to use the protocol 2000.
for its intended purpose. These signatures provide a syntactic spec-
ification for the points in the protocol at which the agents must pro- [12] K. Jensen. Coloured Petri Nets: Basic Concepts, Analysis
vide their own decision-making and information-processing code, Methods and Practical Use, Volume 1: Basic Concepts.
and agent developers could use this to bind internal agent code to Monographs in Theoretical Computer Science. Springer,
these points in the protocol. There is further work to be done to 1992.
find ways of defining the meaning of these operations so that this [13] J. Martin and J. J. Odell. Object-Oriented Methods: A
binding can be performed on a semantic rather than syntactic ba- Foundation. Prentice Hall, Englewood Cliffs, NJ, UML
sis. This will provide the ability for agents to engage in previously edition, 1998.
unknown interaction protocols by interpreting the specifications of
the protocol and its associated ontologies. [14] T. Murata. Petri nets: Properties, analysis and applications.
Proceedings of the IEEE, 77(4), 1989.
6. REFERENCES [15] M. Nowostawski, M. Purvis, and S. Cranefield. A layered
[1] C. Atkinson and T. Kühne. Processes and products in a
approach for modelling agent conversations. In Proceedings
multi-level metamodelling architecture. International
of the 2nd International Workshop on Infrastructure for
Journal of Software Engineering and Knowledge
Agents, MAS, and Scalable MAS, 5th International
Engineering, 11(6):761–783, 2001.
Conference on Autonomous Agents, 2001.
[2] F. Bergenti and A. Poggi. Exploiting UML in the design of http://www.cs.cf.ac.uk/User/O.F.Rana/agents2001/papers/
multi-agent systems. In A. Omicini, R. Tolksdorf, and 06 nowostawski et al.pdf.
F. Zambonelli, editors, Engineering Societies in the Agents
[16] M. Nowostawski, M. Purvis, and S. Cranefield. Modelling
World, Lecture Notes in Computer Science 1972, pages
and visualizing agent conversations. In J. P. Müller,
106–113. Springer, 2000. (an earlier version is available at
E. Andre, S. Sen, and C. Frasson, editors, Proceedings of the
http://lia.deis.unibo.it/confs/ESAW00/pdf/ESAW13.pdf).
Fifth International Conference on Autonomous Agents, pages
[3] G. Booch, I. Jacobson, and J. Rumbaugh. The Unified 234–235. ACM Press, 2001.
Modeling Language User Guide. Addison-Wesley, 1998.
[17] J. J. Odell, H. Van Dyke Parunak, and B. Bauer. Representing
[4] R. Cost, Y. Chen, T. Finin, Y. Labrou, and Y. Peng. Using agent interaction protocols in UML. In P. Ciancarini and
colored Petri nets for conversation modeling. In F. Dignum M. Wooldridge, editors, Agent-Oriented Software
and M. Greaves, editors, Issues in Agent Communication, Engineering, volume 1957 of Lecture Notes in Computer
volume 1916 of Lecture Notes in Artificial Intelligence, Science, pages 121–140. Springer, 2001. (Draft version at
pages 178–192. Springer, 2000. http://www.auml.org/auml/working/Odell-AOSE2000.pdf).
[5] S. Cranefield and M. Purvis. A UML profile and mapping for [18] M. Purvis, S. Cranefield, M. Nowostawski, and D. Carter.
the generation of ontology-specific content languages. Opal: A multi-level infrastructure for agent-oriented
Knowledge Engineering Review, Special Issue on Ontologies software development. Discussion Paper 2002/01,
in Agent Systems, 2002. To appear. Department of Information Science, University of Otago,
PO Box 56, Dunedin, New Zealand, 2002.
[6] D. Fensel, M. Crubezy, F. van Harmelen, and M. I. Horrocks. http://www.otago.ac.nz/informationscience/publctns/
OIL & UPML: A unifying framework for the knowledge complete/papers/dp2002-01.pdf.gz.
web. In Proceedings of the Workshop on Applications of
Ontologies and Problem-Solving Methods, 14th European [19] J. B. Warmer and A. G. Kleppe. The Object Constraint
Conference on Artificial Intelligence (ECAI 2000), 2000. Language: Precise Modeling With UML. Addison-Wesley,
http://delicias.dia.fi.upm.es/WORKSHOP/ECAI00/14.pdf. 1998.
[7] T. Finin, Y. Labrou, and J. Mayfield. KQML as an agent
communication language. In J. M. Bradshaw, editor,
Software Agents. MIT Press, 1997. Also available at
http://www.cs.umbc.edu/kqml/papers/kqmlacl.pdf.
[8] Foundation for Intelligent Physical Agents. FIPA ACL
message representation in string specification.
http://www.fipa.org/specs/fipa00070/, 2000.
[9] Foundation for Intelligent Physical Agents. FIPA interaction
protocol library. http://www.fipa.org/repository/ips.html,
2001.
[10] Foundation for Intelligent Physical Agents. FIPA request
interaction protocol specification, version F.
http://www.fipa.org/specs/fipa00026/, 2001.