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.