Communication and interaction in a multi-agent system devised for transport brokering Lucian Luncean Alex Becheru Romanian-German University of Sibiu University of Craiova Sibiu, Romania Craiova, Romania lucian.luncean@gmail.com becheru@gmail.com the same language to understand each other, but they also need a common representation of concepts. Thus an on- Abstract tology should be part of every agent’s knowledge base to describe concepts and relations among them. In multi-agent systems communication and inter- Another aim of the paper is to rethink and improve the action between individual agents are fundamental information flow within the system, introduced in [15]. We characteristics. In order to fulfil those characteris- will focus our discussion on two scenarios: the information tics, agents have to exchange messages that have a flow starting with the arrival of a transport request for a predefined and agreed format and semantics. Our cargo and the information flow upon picking up a request chosen format for messages is FIPA-ACL, a lan- for adding a transport vehicle to the system. guage widely accepted for agent platforms. In our In order for agents to be able to converse, we needed previous work we proposed a multi-agent system to use a certain Agent Communication Language (ACL). for transport brokering. This paper complements The most popular ACLs are: FIPA-ACL that was pro- our previous work by defining the process of com- posed by the Foundation for Intelligent Physical Agents munication and interaction between agents. An (FIPA) [17] and Knowledge Query and Manipulation Lan- ontology is introduced and evaluated through us- guage (KQML) [19]. age scenarios, with the purpose of defining the In this paper we chose to use FIPA-ACL, as it has a messages’ meanings. high degree of acceptance in the agent programming com- munity and moreover in open systems. Also FIPA1 max- 1 Introduction imises the interoperability across agent-based applications, This paper describes an ongoing effort in developing a services and equipment as it has been implemented in many multi-agent system for transport brokering. Our pro- projects. posed logistics service with brokering functionality is im- An Agent Communication Language is a language with plemented through agent-based negotiation. When a re- a precisely defined syntax, semantics and pragmatics that quest arrives, a virtual supply chain emerges from the sys- is the basis of communication between independently de- tem through automated or semi-automated negotiation pro- signed and developed agents. ACL standard allows encod- cesses between software agents. A software agent is the ing/decoding of information exchange by the agents. fundamental actor in our domain. Across this paper we A basic FIPA-ACL message is composed of several pa- shall be using the term agent instead of software agent. rameters including a performative (i.e. type of the commu- The main purpose of this paper is to define and present nication act of the message), the sender, the receiver and the means of communication between agents in our first the reply-to (i.e. participants in communication), the con- proposed system [14] and improved in [13]. The messages tent (i.e. the content of the message), the used ontology exchanged in our multi-agent system (MAS) shall be repre- (i.e. description of content) and others. Among the param- sented as semantic content. Agents exchange information eters listed above only performative is mandatory. A con- in order to achieve their goals. Therefore agents must speak versation between agents is defined as a sequence of mes- sages exchanged by them. Control of conversation is done Copyright c 2015 for the individual papers by the papers’ authors. Copy- through a protocol parameter that defines the interaction ing permitted only for private and academic purposes. protocol in which the ACL message is generated. Certainly In: A. Bădică, M. Colhon (eds.): Proceedings of the 2015 Balkan Confer- ence on Informatics: Advances in ICT 1 http://www.fipa.org 51 one of the most complex tasks in defining the conversation After a detailed analysis of the three ontologies we decide between agents, is to study all the possible sequences of to improve them in [13]. In the same paper we evaluated messages exchanges that can be performed during the con- all three ontologies through a simple scenario and another versation. A FIPA-ACL message example is illustrated in complex scenario. In this paper we shall introduce the forth Listing. 1. ontology Messages Ontology. 1 [< pe rfo rm ati ve > sender : 2.1 System Architecture 2 r e c e i v e r : content : . . ] Through the proposed system we plan to build a business Listing 1: FIPA-ACL message structure model for logistics brokering in the transport domain. In More information about the structure and the language the context of our work we identified two types of cus- content of FIPA-ACL messages can be found in [5] and [8]. tomers, on one hand cargo owners (named Cargo owners ACLs rely on speech act theory which defines a set of in our system) and on the other hand providers of transport performatives called Communicative Acts. In [6] you can (named Transport providers). These customers are repre- find more details about FIPA Communicative Act Library sented in our system by agents such as aCAgent, respec- (CAL). tively aFTPAgent. Other agents that contributing to the To define the semantics of the FIPA ACL we need an functioning of the system are aFBAgent (Freight Broker formal language called Semantic Language (SL). On-line Agent) that represents the transport brokering service and information about FIPA SL is available in [7]. aFBRAgent (Freight Broker Registry Agent) that manages The paper is organised as follows. The previous work is the requests of customers and transport providers. Thus we presented in Section 2. Section 2.1 is dedicated to the de- identified four types of agents that represent both external scription of the system architecture. Two real use case sce- users of the system, as well as internal system components narios are given in Section 2.2 together with the agent de- with specific capabilities. sign and agent collaboration. Information flow in the sys- We distinguished four major parts of the system: (1) tem can be found in Section 3. Also in the previous section the Request Side for agents and activities representing cus- we define the message structure and message content on- tomers, (2) the Freight Broker Side where the freight bro- tology. Section 4 presents some relevant related work and ker’s agent act, (3) the Freight Transport Provider Side Section 5 is dedicated to conclusions and future work. where activities related to the carrier take place and (4) the Freight Broker Registry side where Customer Data and 2 Background Freight Transport Provider Data are stored. In recent years the development of Internet applications has The system diagram illustrating the types of agents and known a considerable growth both in quality and quantity. their acquaintance relations are presented in Figure. 1. Many entrepreneurs have identified an opportunity to in- In [15] you can find more details about description and crease their business. One of these opportunities is the con- comportment of all agents mentioned above. The dia- stant struggle to automate operations. In [15] we proposed gram is of UML (Unified Modelling Language) type, while an agent-based system for brokering of logistics services. agent types are represented using agent stereotype. Agent We consider a broker position in a transport company hold- acquaintance relations are represented as UML associa- ing a Website where requests and offers are posted. Re- tions [9]. quests are posted by the cargo owners and offers are posted by the providers of freight. Both the transport provider and the cargo owner are continuously seeking transport oppor- tunities. The role of the freight transportation broker is to match requests with offers, such that goods are transported in optimal conditions. The broker has to take in consider- ation the time constraints and vehicle capabilities. An im- portant issue is the minimisation of the movement without cargo along the routes chosen between the points of charge and discharge. Thus the broker has to determine the optimal routes for the transport vehicles in order to eliminate as much as pos- Figure 1: System Diagram sible the movement of vehicle without cargo, thus reducing transport costs (i.e. reducing logistics costs). 2.2 Usage Scenario In [14] we proposed four ontologies and we introduced only three ontologies such as: Transport Request Ontol- Following the analysis made in [15] we identified two ogy, Transport Resource Ontology and Freight Ontology. main scenarios. The first scenario refers the possibility 52 of allowing customers (i.e. cargo owners) to make trans- • What heuristics and guidelines tell us when to apply port requests. The second scenario should allow transport what principle? providers (i.e. transport providers) to add their resource (i.e. vehicle) to a freight broker. In [18] agent collaboration was defined as the exchange The two proposed usage scenarios are very similar with of data among information-processing agents, regardless of those in [4]. In the first case a set of requirements (i.e whether the exchange is productive or not. constrains) is matched against a description of a resource, Thus we designed communication diagrams for the two while in the second case a description of the resource is usage scenarios that are presented in Figures. 2 and 3. Dur- matched against a set of requirements. Let us assume ing the design we identified some similar features of ACL that customers, both the cargo owners and the transport messages such as intentions (e.g. request, agree, forward, providers are already registered and logged in our system inform, query, search, response), attendees (aCAgent, aF- (i.e. Freight Broker’s Website). BAgent, aFTPAgent and aFBRAgent), a content (i.e. the First, let us to assume that one of the customers formu- certain information that is exchanged), content description lates a request to the transport company to solicit transport and conversation control (e.g. communication protocol). of flat doors between addresses A and B. Also the customer Let us now focus our attention on the flow of informa- mentions in the request form that the weight of the flat tion that is necessary to facilitate the two proposed scenar- doors is 3000 kg. ios mentioned before. Secondly, let suppose that a transport provider (also named customer from the point of view of the broker) 3 Information flow in the system wants to make available its transport vehicle on the Freight Broker’s Website. The transport resource must be a vehicle The aim of this section is to discuss the way in which the in- with some of the following capabilities: type of vehicle (re- formation flow and data transformations involved in it are garding the number of axes), vehicle dimensions, dedicated implemented. In our system information exchange takes vehicle, etc. place separately between agent that represent the Freight Broker (FBAgent) and each agent that represent the Cus- 2.3 Agent design tomer (CAgent), the Freight Broker (FBAgent), the Freight Transportation Provider (FTPAgent) and the Freight Bro- According to [2] agents are fundamentally a form of dis- ker Registry (FBRAgent). tributed code process and thus comply with the classic The two main interaction scenarios are: (i) the cargo notion of a distributed computing model comprising two owners, represented by their CAgents make a transport re- parts: components and connectors. Components are con- quest and pay for provided service through the broker and sumers, producers and mediators of communication mes- (ii) the transport providers, represented by the FTPAgents sages exchanges via connectors. FIPA-ACT theory states want to earn capital by lending their resources to the broker. that messages represent actions or communicative acts (i.e. speech acts or performative). The agents must be designed We assume that in both scenarios the customers, the to allow fluent and flexible natural language communica- cargo owners and the transport providers are logged into tion in a manner similar to human negotiators. the system as in [12]. The interaction between an agent in the system and an external agent is not the aim of our 2.4 Agent collaboration current paper, this subject is presented in [11]. Figure. 2 represents the process taking place upon the Collaboration among different agents operating in the sys- arrival of a request from a cargo owner on the Freight Bro- tem implies communication between them, which is a fun- ker’s Website. damental characteristic of MAS. During our research we Listing. 2 presents in an algorithmic detailed fashion the discovered challenging problems that arise when agents try above mentioned figure. The first line of the algorithm rep- to communicate and collaborate with each other in order resents communication (i.e. interaction) between a human to reach and agreement (i.e contract). In our case an exam- user and its respective agent in our system, aCAgent. Next ple of such collaborations is the price negotiation, transport the aCAgent forwards the request to aFBAgent using the time and quality. According to [20] the following question messageForwardRequest class from our ontology. On the emerge in the design phase of such systems: third line, the aFBAgent sends a query message to the aF- BRAgent. The query is an interrogation of the database for • How should messages be generated, transmitted and retrieving all matching vehicles, based on the constraints represented? defined by the cargo owner. If matching vehicles could be • How can the content of messages be standardised? found, the list of vehicles is sent by the aFBRAgent to aF- BAgent (lines 4-8). The result of the negotiation process, • What principles (e.g. concepts, mechanisms and pat- either success of failure, is sent to the collaborating agents terns) can be used? (lines 9-19). Else if not matching vehicle could be found 53 the aFBAgent, aCAgent and CargoOwner are notified with 3.2 Message Content Ontology mismatch messages. Ontologies play a significant role not only in the agent com- Figure. 3 presents a sequence of actions started by the munication, but also in knowledge capturing, sharing and transport provider, represented by the aFTPAgent, which reuse. One of the main reasons why ontologies are being desires to add a transport vehicle on the Freight Broker’s used is semantic interoperability. Thereby, as we specified Website. The detailed version of the above mentioned fig- in [13] we have decided that the request, the freight, the ure is presented in Listing. 3 in an algorithmic fashion. transport resource and the messages exchanged between agents used by the system must be semantically repre- 3.1 Message Structure sented. When agents want to communicate, an appropriate mes- Here we present our proposed message structure based on sage content ontology is selected. This ontology is used by FIPA-ACL. As an example of a request communicative act, agents to make conversation about issues related to specific consider agent aCAgent (that represents the cargo owner) domain. requesting agent aFBAgent (that represents the Freight FIPA communication stack can be separated into seven Broker) to process an order from “TRANS LTD” consisting sub-layers such as: transport, encoding, messaging, ontol- of 10 pallets with flat doors to be transported from Sibiu to ogy, content expression, communicative act and interaction Bucureşti. This offer is only available for the next 24 hours. protocol. The request was made in 2015.05.01, date of charge was Considering that although FIPA allows for the use of on 2015.05.03 and date of discharge was on 2015.05.04. In ontologies when expressing messages content, it does not FIPA notation, we express the request as in Listing. 4. specify any particular representation for ontologies or pro- vide any domain-specific ontologies. In this section we 1 ( request propose to provide a messages ontology for our multi-agent 2 : s e n d e r aCAgent system. This ontology was generated considering initial ar- 3 : r e c e i v e r aFBAgent chitecture presented above. In fact this proposed messages 4 : r e p l y −by : hasTTL = 2 4 : 0 0 : 0 0 5 : c o n t e n t ( d e l i v e r hasOwnerName = ”TRANS LTD” ontology is a vocabulary that help us to express the content 6 hasDateOfRequest =”2015.05.01” of messages exchanged between agents in the system. For 7 h a s N u m b e r O f B o x O f F r e i g h t =”10” the development of the ontology we followed an engineer- 8 h a s N a m e O f F r e i g h t =” f l a t d o o r s ” 9 hasStartMomentOfCharge =”2015.05.03” ing methodology as in [23]. 10 hasStartMomentOfDischarge =”2015.05.04” First, we need to define some specific terms of scien- 11 P o i n t O f D i s p a t c h =” S i b i u ” tific literature used from now such as: ontology, message, 12 P o i n t O f D e s t i n a t i o n =” B u c u r e s t i ” ) content, conversation and protocol. 13 : r e p l y − w i t h r e q u e s t −01 14 : language s l An ontology is used to represent knowledge that is 15 : ontology lob shared between different entities. It provides terms and vo- 16 : conversation −id request123 ) cabulary used to represent knowledge so that both sender Listing 4: Example of a FIPA-ACL request message and receiver can understand. According to [17] a message is an individual unit of We mention that the freight is transported on pallets, a communication between two or more agents. A message pallet can transport a maximum of 5 flat doors. To express corresponds to a communicative act, in the sense that a the quantity we use the class BoxOfFreight that represents message encodes the communicative act for reliable trans- the wrapping of the freight. To capture the number of boxes mission between agents. Note that communicative acts can we use the property hasNumberOfBoxOfFreight. be recursively composed, so while the outermost act is di- An example where an agent accepts the request is pre- rectly encoded by the message, taken as a whole a given sented in Listing. 5. message may represent multiple individual communicative acts. A content of the message is a part of a communicative 1 ( agree act and denotes the content of the message. In [5] the mean- 2 : s e n d e r aFBAgent ing of the content of any ACL message is intended to be 3 : r e c e i v e r aCAgent 4 : r e p l y − t o r e q u e s t −01 interpreted by the receiver of the message. This is particu- 5 : language s l larly relevant for instance when referring to referential ex- 6 : o n t o l o g y lob . message pressions, whose interpretation might be different for the 7 : conversation −id request124 sender and the receiver. 8 ) A protocol is a special set of rules, used by end points in Listing 5: Example of a FIPA-ACL agree message a connection, in order to establish and maintain communi- cation. Protocols specify interactions between the commu- 54 Figure 2: Communication diagram for a request made by the cargo owner in the broker’s Website classes of messageForward are defined here: messageFor- wardRequestVehicle related to the first scenario, message- ForwardRequest related to both scenarios defined in sec- tion 2.2, and messageForwardAddVehicle related to the sec- ond scenario. E.g. AddVehicleNotificationOfFailure is a subclass of messageForwardRequestAddVehicle therefore this subclass is related to the second scenario. Further we see that this subclass is equivalent to messageOfResultAd- dVehicleFailure which is a message sent by aFBAgent to aFTPAgent when a vehicle could not be added to aFBRA- gent, but our current subclass has as sender aFTPAgent and receiver TransportProvider. Thus AddVehicleNotifica- Figure 3: Sequence diagram for adding a freight provider tionOfFailure is a forward message. in the broker’s system The class messageOfResult defines messages sent by aFBAgent after the process of negotiation (first scenario) nicating entities. Further information about protocols and or after aFBRAgent has received the request to add a vehi- agents communication are defined by Amit K. Chopra’s cle in the system data base (second scenario). Otherwise [3]. said these messages conclude the processes in both scenar- In our scenario, we use the ontology to define the types ios. These type of messages are then forwarded through the of message exchange between agents, this completes our messageForward messages. already developed ontologies. All the ontologies developed All the messages received by aFBRAgent are defined by through this research project are available online2 . the messageToDb class. Also this class has two other sub- The top level class of our ontology is the message, see classes: messageToDbQuery which contains only queries Figure. 4, which in turn is also a Thing. We then dived the (i.e. interrogations), and messageToDbUpdate comprising message in other 4 subclasses: messageForward, message- of messages that update the system data base. For exam- OfResult, messageToDb and messageFromDb. The separa- ple, after the negotiation is finished with aCAgent in the tion was based on the the general purpose of the messages first scenario and a vehicle (V) is chosen aFBAgent sends in our system. an update message to aFBRAgent to set vehicle V as occu- The messageForward class describes messages that are pied for the time of the transport. being forwarded, the message content does not change, The class messageFromDb describes messages that con- only the sender and receiver change. Three other sub tain data structures needed in the process of negotiation (first scenario). These data structures are either obtained 2 intelligentdistributedsystems.github.io/FreightOntology/ from the system data base or from the negotiation process 55 1 CargoOwner −>aCAgent 2 aCAgent −>aFBAgent : m e s s a g e F o r w a r d R e q u e s t 3 aFBAgent −>aFBRAgent : messageToDbQueryRequest 4 IF s u c c e s s i n f i n d i n g matching v e h i c l e s 5 aFBRAgent−>aFBAgent : messageFromDbDataStructureLMV 6 aFBAgent −>aFBRAgent : m e s s a g e T o D b Q u e r y E x t r a D a t a 7 aFBRAgent−>aFBAgent : messageFromDbDataStructureLMVP 8 aFBAgent n e g o t i a t i o n p r o c e s s w i t h aCAgent : 9 IF n e g o t i a t i o n s u c c e s s : 10 aFBAgent −>aCAgent : m e s s a g e O f R e s u l t R e q u e s t V e h i c l e S u c c e s s 11 aCAgent −>CargoOwner : R e q u e s t V e h i c l e N o t i f i c a t i o n O f S u c c e s s 12 aFBAgent −>aFTPAgent : m e s s a g e O f R e s u l t R e q u e s t V e h i c l e S u c c e s s 13 aFTPAgent −> T r a n s p o r t P r o v i d e r : R e q u e s t V e h i c l e N o t i f i c a t i o n O f S u c c e s s 14 aFBAgent −>aFBRAgent : m e s s a g e T o U p d a t e I n f o V e h i c l e 15 ELSE n e g o t i a t i o n f a i l e d : 16 aFBAgent −>aCAgent : m e s s a g e O f R e s u l t R e q u e s t V e h i c l e F a i l e d 17 aCAgent −>CargoOwner : R e q u e s t V e h i c l e N o t i f i c a t i o n O f F a i l u r e 18 aFBAgent −>aFTPAgent : m e s s a g e O f R e s u l t R e q u e s t V e h i c l e F a i l e d 19 aFTPAgent −> T r a n s p o r t P r o v i d e r : R e q u e s t V e h i c l e N o t i f i c a t i o n O f F a i l u r e 20 ELSE f a i l u r e i n f i n d i n g match v e h i c l e s 21 aFBRAgent−>aFBAgent : m e s s a g e O f R e s u l t R e q u e s t V e h i c l e M i s m a t c h 22 aFBAgent −>aCAgent : R e q u e s t V e h i c l e N o t i f i c a t i o n O f M i s m a t c h 23 aCAgent −>CargoOwner : R e q u e s t V e h i c l e N o t i f i c a t i o n O f F a i l u r e Listing 2: First scenario of message exchange between agents 1 T r a n s p o r t P r o v i d e r −>aFTPAgent 12 2 aFTPAgent −>aFBAgent : m e s s a g e F o r w a r d R e q u e s t Listing 6: Example of a primitive class in the Messages 3 FBAgent −>aFBRAgent : messageToDbUpdateAddVehicle 4 aFBRAgent −>aFBAgent : Exchange Ontology messageFromDbRegistrationResponse 5 IF r e g i s t r a t i o n s u c c e s s : 6 aFBAgent −>aFTPAgent : messageOfResultAddVehicleSuccess 4 Related Work 7 aFTPAgent −> T r a n s p o r t P r o v i d e r : AddVehicleNotificationOfSuccess The authors of [16] proposed ontology-services to facil- 8 ELSE r e g i s t r a t i o n f a i l u r e : itate agents’ interoperability. By defining this ontology 9 aFBAgent −>aFTPAgent : they provide a vocabulary to be used in the communication messageOfResultAddVehicleFailed 10 aFTPAgent −> T r a n s p o r t P r o v i d e r : among different agents. AddVehicleNotificationOfFailure We found a similar approach to ours in [22], the authors Listing 3: Second scenario of message exchange between present an overview of issues concerning allocation of pro- agents cesses in the grid through negotiations. Paper [10] discusses the implementation of information flows and data transformations. As well as in our paper with aFTPAgent, see messageFromDbDataStructure sub- information about products are ontologically represented. class. For the second scenario messageFromDb defines An ontology whose aim is to share information between messages sent by aFBRAgent after the process of vehi- sending and receiving agents in Multi-Agent System is pre- cle addition was tried. Let us suppose that a vehicle was sented in [1]. The challenge targeted by the authors was the not registered because it is already present in the system interactions among agents as agent-agent and agent-user data base, then aFBRAgent should send a message to aF- communication can be very complex. BAgent containing an error line Update failure, (object al- Van Aart et.al.[21] constructed a theoretical framework ready present...). for message-based communication between agents. As in the current paper, the meaning and intention of the mes- 1 Class : sages is specified through a message content ontology. 2 3 Annotations : 4 r d f s : comment 5 Conclusions and Future Work 5 ” Message f o r m a t : 6 Request r e q u e s t i d f a i l e d ” In this paper we have introduced the means of communica- 7 EquivalentTo : tion between the agents in our MAS. Also we detailed the 8 way in which agents interact with each other. 9 SubClassOf : 10 One of the most important issues in the area of agent 11 D i s j o i n t W i t h : communication is the understanding of messages content 56 Figure 4: Infered Ontology Diagram meaning. We proposed and introduced a message content References ontology to capture the meaning of messages [1] M. Arora and M. S. Devi. Ontology based agent As a future work, we intend on the short term to develop communication in resource allocation and monitor- our messages ontology with messages exchanged during ing. IJCSI, page 27, 2010. the negotiation process. Also we shall develop/adapt an algorithm to sort the list of transport resources (lmv) de- [2] F. L. Bellifemine, G. Caire, and D. Greenwood. De- pending on collaboration history of customers (transport veloping Multi-Agent Systems with JADE (Wiley Se- providers) and their reputations. On the long term we pro- ries in Agent Technology). John Wiley & Sons, 2007. pose to develop an application-based system using several [3] A. K. Chopra and M. P. Singh. Agent communication. agents and collect real data for experiments. In G. Weiss, editor, Multiagent Systems, chapter 3, 101-142, MIT Press, 2013. [4] M. Drozdowicz, K. Wasielewska, M. Ganzha, M. Pa- przycki, N. Attaoui, I. Lirkov, R. Olejnik, D. Petcu, 5.0.1 Acknowledgements and C. Bădică. Ontology for contract negotiations in an agent-based grid resource management system. In This work was supported by the strategic grant POS- P. Iványi and B. Topping, editors, Trends in Paral- DRU/159/1.5/2/133255. Project ID 133225(2014), co- lel, Distributed, Grid and Cloud Computing for En- financed by the European Social Fund within the Secto- gineering, Computational & Technology Resources, rial Operational Program Human Resources Development chapter 15, pages 335–354. Saxe-Coburg Publica- 2007-2013. tions, 2011. 57 [5] FIPA. Fipa acl message structure specification. [16] A. Malucelli and E. da Costa Oliveira. Ontology- http://www.fipa.org/specs/fipa00061/SC00061G. services to facilitate agents’ interoperability. In Intel- html#_Toc26669708. ligent Agents and Multi-Agent Systems, volume 2891 of Lecture Notes in Computer Science, pages 170– [6] FIPA. Fipa communicative act library specifi- 181. Springer Berlin Heidelberg, 2003. cation. http://www.fipa.org/specs/fipa00037/ SC00037J.html#_Toc26729689. [17] S. Poslad. Specifying protocols for multi-agent sys- tems interaction. ACM Trans. Auton. Adapt. Syst., [7] FIPA. Fipa sl content language specification. [online]. 2(4), Nov. 2007. [8] N. Fornara, D. Okouya, and M. Colombetti. Us- [18] N. S. Talukdar. Collaboration rules for autonomous ing owl 2 dl for expressing acl content and seman- software agents. Decision Support Systems, 24(3- tics. In Proceedings of the 9th European Conference 4):269–278, 1999. on Multi-Agent Systems, EUMAS’11, pages 97–113. Springer-Verlag, 2012. [19] F. Tim, R. Fritzson, D. McKay, and R. McEntire. Kqml as an agent communication language. In Pro- [9] M. Fowler. UML Distilled: A Brief Guide to the ceedings of the third international conference on In- Standard Object Modeling Language (3rd Edition). formation and knowledge management, CIKM, pages Addison-Wesley Professional, 2003. 456–463, 1994. [10] M. Gawinecki, M. Ganzha, P. Kobzdej, M. Paprzy- [20] C. van Aart, G. Caire, F. Bergenti, and R. Pels. Cre- cki, C. Bădică, M. Scafes, and G.-G. Popa. Manag- ating and using ontologies in agent communication. ing information and time flow in an agent-based e- In Proceedings of the Workshop on Ontologies in commerce system. In ISPDC, pages 352–359. IEEE Agent Systems, 1st International Joint Conference on Computer Society, 2006. Autonomous Agents and Multi-Agent Systems, AA- MAS’02, 2002. [11] M. Gawinecki, M. Gordon, P. Kaczmarek, and M. Pa- przycki. The problem of agent-client communication [21] van Aart, Chris and Wielinga, Bob and Schreiber, on the internet. Scalable Computing: Practice and Guus Message Content Ontologies Ontologies for Experience, 6(1):111–123, 2005. Agents: Theory and Experiences, Whitestein Series in Software Agent Technologies, Tamma, Valentina [12] S. Ilie, C. Bădică, A. Bădică, L. Sandu, R. Sbora, and Cranefield, Stephen and Finin, TimothyW. and M. Ganzha, and M. Paprzycki. Information flow in Willmott, Steven Birkhuser Basel, pages 169-200. a distributed agent-based online auction system. In D. D. Burdescu, R. Akerkar, and C. Bădică, edi- [22] K. Wasielewska, M. Ganzha, M. Paprzycki, M. Droz- tors, Proceeding of 2nd International Conference on dowicz, D. Petcu, C. Bădică, N. Attaoui, I. Lirkov, Web Intelligence, Mining and Semantics, WIMS’12, and R. Olejnik. Negotiations in an agent-based page 42. ACM, 2012. grid resource brokering system. In P. Iványi and B. Topping, editors, Trends in Parallel, Distributed, [13] L. Luncean, A. Becheru, and C. Bădică. Initial eval- Grid and Cloud Computing for Engineering, Com- uation of an ontology for transport brokering. Pro- putational & Technology Resources, pages 355–374. ceeding of 19th IEEE International Conference on Saxe-Coburg Publications, Stirlingshire, UK, 2011. Computer Supported Cooperative Work in Design – CSCWD 2015, 2015. [23] Natalya F. Noy and Deborah L. McGuin- ness. Ontology Development 101: A [14] L. Luncean and C. Bădică. Semantic modeling of in- Guide to Creating Your First Ontology. formation for freight transportation broker. In Pro- Stanford University, Stanford, CA, 94305. ceeding of 16th International Symposium on Symbolic http://protege.stanford.edu/publications/ and Numeric Algorithms for Scientific Computing – ontology_development/ontology101.html, 2014 SYNASC 2014, pages 527–534. IEEE Computer So- ciety, 2014. [15] L. Luncean, C. Bădică, and A. Bădică. Agent-based system for brokering of logistics services - initial re- port. In Intelligent Information and Database Sys- tems - 6th Asian Conference, ACIIDS 2014, Bangkok, Thailand, April 7-9, 2014, Proceedings, Part II, pages 485–494. Springer, 2014. 58