Implementation of FIPA Ontology Service Hiroki Suguri* Eiichiro Kodama** Masatoshi Miyazaki** suguri@comtec.co.jp kodama@iwate-pu.ac.jp miyazaki@iwate-pu.ac.jp Hiroshi Nunokawa*** Shoichi Noguchi*** nunokawa@sfais.or.jp noguchi@sfais.or.jp ABSTRACT intended to verify the normative technical specifications and The authors have implemented FIPA 98 Spec 12: Ontology to promote the development and deployment of agent-based Service. In addition, we developed a sample application of on- applications. line shopping service that integrated multiple database In 1998, FIPA produced second set of specifications: FIPA 98. schemata using the ontology service to verify and demonstrate FIPA 98 includes normative specifications of Spec 8: Human- the specification and the implementation. In this paper, we Agent Interaction, Spec 10: Agent Security Management, Spec briefly introduce FIPA and FIPA Specifications at first. Next, 11: Agent Management Support for Mobility and Spec 12: we describe Comtec Agent Platform, on which the ontology Ontology Service [3]. Spec 1: Agent Management and Spec 2: service is deployed. Then, after reviewing the ontology Agent Communication Language were also revised and service specification and its relationship with OKBC, we updated. discuss details of the implementation of the ontology service and demonstration application. We conclude with a prospect Comtec Corporation (in October 2000, Communication of real-world applications in the Agentcities project and future Technologies was established by the management buyout of works that we are currently preparing for. Comtec Corporation) implemented FIPA 97 Specs 1-3 and released the source code of world’s first free implementation of FIPA in September 1998. In October 1999, Comtec added the Keywords implementation of Spec 12: Ontology Service to its agent Practical experience, Standardisation issues, Implications on platform and also made the source code open to public. A live agent internal structure, Component architectures for agents, service of Comtec Agent Platform had been offered in order to FIPA, Ontology Service, OKBC, Agentcities.****** facilitate the global interoperability trials of FIPA-based agent platforms using the Internet since February 9, 1999, following 1. INTRODUCTION the first interoperability trials at FIPA Seoul meeting in FIPA (The Foundation for Intelligent Physical Agents, January 1999. Unfortunately, the live service has been stopped http://www.fipa.org/) is a non-profit organization aimed at during the chaos of the transition of the company from Comtec producing standards for the interoperation of heterogeneous Corporation to Communication Technologies [6]. software agents. The purpose is realized by publishing a set of In October 1999, FIPA decided that it no longer abide by a specifications so that the agents developed by different yearly cycle (such as FIPA 97 and FIPA 98) and release the vendors can talk to each other based on the standard specifications asynchronously. FIPA also undertook major specifications. restructuring of the organization and introduced a new In 1997, FIPA introduced its first set of specifications called document policy and lifecycle management of the FIPA 97. FIPA 97 specifications include Spec 1: Agent specifications. According to the new lifecycle schema of the Management, Spec 2: Agent Communication Language, Spec specifications, the documents follow the steps below: 3: Agent/Software Integration and four other application (1) Preliminary, where the technical committee decides that specifications. Specs 1-3 are called normative specifications the document is worth public review; that prescribe technical aspects of multi-agent systems like how agents are managed, what language and interaction (2) Experimental, where FIPA Architecture Board, the top protocols agents use to communicate with each other, and how technical authority within FIPA, confirms that agents and non-agent software interact in the Internet. Four experimental implementation and interoperability trials application specifications are called informative, which are of the implementations is encouraged; (3) Standard, where the interoperability of the multiple * implementations by different developers has been Communication Technologies. 2-15-28-6F Omachi Aobaku, Sendai 980-0804 Japan. Tel +81-22-222-2591 achieved; and ** Iwate Prefectural University. 152-52 Takizawa-aza-sugo, (4) Deprecated and Obsolete where documents are no longer Takizawa, Iwate 020-0173 Japan. Tel +81-19-694-2000 valid and archived for historical reference purpose only. *** Sendai Foundation for Applied Information Sciences. 5-12- As of April 2001, most of the latest specifications are at the 55 Tsutsujigaoka Miyaginoku, Sendai 983-0852 Japan. Tel Experimental stage. Such specifications include abstract +81-22-298-9653 architecture, agent management, agent communication language and content languages, interaction protocols, Transport mechanism, or IPMT. The communications protocol message transports and message encodings, agent/software used in IPMT is not specified by FIPA so that agents can use integration, and ontology service [4]. Previous FIPA 97 and platform-specific or programming language dependent FIPA 98 specifications are now Obsolete status. message transport mechanisms such as Unix IPC, Java RMI, Unfortunately, Comtec agent platform is based on FIPA 97 HTTP, SMTP etc. To ensure the communications between and FIPA 98. It is currently not yet fully compatible with the agents on different agent platforms that use different IPMT latest Experimental specifications. Since FIPA 97 and FIPA protocols, the ACC must speak common ‘baseline protocol’, 98, there are some major changes in agent management and which is CORBA IIOP to forward the message to ACCs on other message transport in the latest specifications. However, the platforms. differences between FIPA 98 Spec 12: Ontology Service and the latest experimental ontology service specification are just cosmetic and there is no functional change. 2. COMTEC AGENT PLATFORM Comtec Agent Platform is a straightforward implementation of agent management, agent communication language and agent/non-agent software integration functions of the FIPA 97 specifications. Figure 1 shows the basic building blocks of the platform. Application Agents (Non-agent Software Integration and Ontology Service) Figure 2. Agent platform configuration models Agent Platform Agents (ACC, AMS and DF) Agent Communication Language Library Comtec’s implementation simplifies the FIPA reference model by using IIOP as the internal messaging protocol, too. Kawa Scheme Interpreter Java IDL Therefore, ACC is responsible for both inter- and intra- platform message exchange. Figure 3 below details out how an Java 2 Standard Edition (JDK 1.2) agent talks to the ACC. Figure 1. Basic building blocks of Comtec Agent Platform Java 2 is the foundation for the platform. Hardware and operating system independency is achieved by using Java. Kawa [1] is a Scheme (a dialect of LISP) interpreter written in Java. Kawa allows Scheme programmers to access Java classes and vice versa. Java IDL is adopted to implement IIOP-based communication between agents as specified by the agent management. Agent communication language library is a collection of primitives of ACL communicative acts, content language interpreters SL0 and SL2, basic design patterns of an Figure 3. Agent communications agent, and interaction protocol handlers. Agent Platform agents are ACC (Agent Communication Channel), AMS (Agent Management System) and DF (Directory Facilitator). (N.B., In this picture, agents (agent-a and ACC) are composed of two ACC is no longer an agent in the latest Experimental parts. The main part is written in Kawa Scheme, which controls specification.) On top of the platform agents are the agent’s behavior. The communications interface utilizes Java application agents such as ARB (Agent Resource Broker) and IDL to use IIOP transport protocol. To establish the software wrapper agents of agent/software integration, and communications between the agents, COS naming service ontology server and ontology client agents of the Ontology (tnameserv) is employed for name resolving. The ACC Service specification. registers the server (receiver) reference with the COS naming Figure 2 depicts the difference between Comtec’s service and agent-a (sender) retrieves the object reference from implementation and FIPA’s reference model of the the naming server. Agent-a sends a message to ACC using the configuration of the agent platform. With FIPA 97 reference IOR and ACC then forwards the message to the recipient agent model, agents communicate via Internal Platform Message (the recipient address is specified in the :receiver slot of the ACL message) with the same manner (which is not described in modified a little to better emphasize the role of OKBC, shows Figure 3). the reference model of FIPA Ontology Service. 3. FIPA ONTOLOGY SERVICE Ontology Designer SPECIFICATION After the initial release of the Agent Communication Language specification, FIPA Technical Committee C, which was Ontology Ontology Ontology responsible for the agent communications, began the work of Server 1 Server 2 Server (Ontoli ngua) (Loom) (Cyc) ontology service in January 1998. Since the basic framework of the agent communications was established by specifying OKBC Backend the ACL, content language SL and interaction protocols such OKBC Frontend Non-FIPA Components as contract net and auctions, it seemed natural to proceed to Ontology A gent FIPA Components deal with the problem of how agents can share a common ontology in order to make a meaningful conversation. The task finished in October 1998 and the document was Message Transport Servi ce published as FIPA 98 Specification Part 12: Ontology Service. The original document itself has been in obsolete status since revised version was edited according to the new document Ontology Client Ontology Client Ontology Client management and lifecycle policy described above. However, DF, AMS etc. the differences between the old and new documents are mostly Agent 1 Agent 2 Agent 3 cosmetic and no significant change has been made. A Japanese translation of the original FIPA 98 specification [5] is also Figure 4. Ontology Service reference model (modified) available, which was made by Intelligent Agent Society of Japan. FIPA ontology service is basically an agent wrapper of OKBC The FIPA Ontology Service specification adopts OKBC [2]. Open Knowledge Base Connectivity, or OKBC, is a set of knowledge model as FIPA-meta-ontology (that is, an ontology applications programming interfaces (API) that connects front- that is used to access the Ontology Agent). It also defines end user applications and back-end knowledge bases (KBs). actions and a predicate used in the content of the conversation Like ODBC (Open Data Base Connectivity) or JDBC (Java Data with the OA, which are shown in Tables 1 and 2 below. FIPA- Base Connectivity), OKBC connects to a wide variety of KB ontol-service-ontology consists of these actions, predicate servers (such as Ontolingua, Loom and Cyc) in the back-end and FIPA-meta-ontology. For the complete list of FIPA-meta- while allowing the client user applications to be able to access ontology, see the OKBC specification, part of which is also these KBs via standardized front-end API. The reference included in the FIPA Ontology Service specification with the implementation of OKBC, which is available from Artificial permission of the original authors. Intelligence Center of SRI International and Knowledge Systems Laboratory of Stanford University, comes with C, Java and Common Lisp programming language bindings of the API. Table 1. Predicate defined in FIPA-ontol-service-ontology OKBC specification also defines a frame-based knowledge Predicate Description model written in KIF that is used to describe the contents of the API. (ontol- It is true if and only if there is a relationship relationship of type level between the The problem with OKBC in FIPA perspective is that its client- ontology o1 and the ontology o2. server model API does not fit for the FIPA agent standard style where communicative interface of the agent is specified but ) programming language API is outside the scope of the specification. Therefore, FIPA decided to wrap the OKBC front-end API with ACL-speaking agent, which is called Table 2. Actions defined in FIPA-ontol-service-ontology Ontology Agent (OA). (The back-end KBs are mentioned as Actions Description ontology server.) Client agents of the OA utilize standard FIPA ACL (query-if, query-ref, request etc.), interaction (assert This action asserts the predicate in protocols (FIPA-request and FIPA-query), white page and ) the ontology specified by yellow page directory services (DF and AMS) and agent the :ontology parameter of the ACL. message transport (IMTP/ACC) to talk to the OA in order to This action retracts (cancels) the (retract access the ontology service behind the OA. Ontology clients ) predicate in the ontology specified store, modify, delete or query the ontology with the OA to by the :ontology parameter of the share the common ontology with other client agents. Figure 4 ACL. below, which is taken from the specification document and (atomic- This action introduces a transaction- The development of the OA is divided into two parts. The first sequence type sequence of actions, which is part is an interface to the OKBC front-end. From OKBC point *) treated as if it was a single action. The of view, the OA is one of the front-end user applications. This result of the action is one of the two part is also responsible for managing OKBC knowledge model cases: (1) all actions are successfully and FIPA-meta-ontology. The second part is the FIPA interface done; or (2) none of the actions is where the agent wrapper is implemented. The FIPA interface made. It is used to modify an existing includes functions such as ontology naming, ontology ontology by combining the actions of relationship and FIPA-ontol-service-ontology management. It retraction and assertion, for example. utilizes existing interaction protocol handlers for FIPA-query The mechanism to maintain the and FIPA-request, which are prescribed in the specification for consistency inside the sequence client agents to talk to the OA. The content language SL2 (rollback if necessary) and to protect interpreter from the agent communication language libraries of values from outside the sequence is the Comtec Agent Platform is also used to express the actions, dependent on the implementation. objects and predicates in the ACL message. (translate Translates the expression as specified 4.1 OKBC Interface by the translation-description. The OKBC interface connects to the OKBC front-end using the ) interaction protocol. OKBC interface. The specification includes two informative annexes. One of them sets forth an introduction to logical foundations of the ontology and conceptualization, contributed by Nicola Guarino (LADSEB-CNR). The other describes guidelines to define a new ontology used by the applications, contributed by Assuncion Gomez-Pérez (Universidad Politécnica de Madrid). Figure 6. OKBC interface 4. IMPLEMENTATION OF THE ONTOLOGY SERVICE The implementation of the Ontology Service specification is It performs the following functions: pretty straightforward based on the specification. Figure 5 z Connecting to and disconnecting from the OKBC front- shows the overall view of the internal composition of the end; ontology agent. z Creating, deleting and identifying a back-end knowledge base; z Operations on frames, slots and facets including creating, modifying and deleting them; z Operations on class and individual hierarchies; z Operations on predicates associated with the frame- sentence; z Converting the SL symbols and the OA predicates to the OKBC objects and the OKBC predicates, and converting vice versa; z Converting the SL actions to the OKBC operations and the OKBC results to the SL expressions; and z Handling of the OKBC errors. Depending on the severity, it either disconnects from OKBC or generates appropriate exceptions and SL error expressions to be passed to the FIPA interface. 4.2 FIPA Interface The FIPA interface is an agent wrapper that takes care of Figure 5. Overview of the ontology agent generating and interpreting SL actions and predicates, and ACL communicative acts based on appropriate interaction protocols. It also processes the registration with DF, and management of ontology names and relationship between the Weakly- The source ontology O1 is ontologies. Figure 7 below displays the internal composition Translatable weakly translatable to the of the FIPA interface. target ontology O2. Strongly- The source ontology O1 is Translatable strongly translatable to the target ontology O2. Approx- The source ontology O1 is Translatable approximately translatable to the target ontology O2. Please look at the specification document for the complete Figure 7. FIPA interface description of these relations. It should be noted here, however, that the following properties hold between the levels of relationships: The following are descriptions of the sub-modules. • Strongly-Translatable ⇒ 4.2.1 Naming and Referring Ontologies Weakly-Translatable ⇒ This sub-module processes naming of ontologies. Each Approx-Translatable ontology must have a unique logical name, which is used in the :ontology slot of the ACL message. The logical ontology • Equivalent (O1, O2) ⇒ name corresponds to the physical name of the KB that is Strongly-Translatable (O1, O2) ∧ connected to the back-end of OKBC. The ontology name Strongly-Translatable (O2, O1) database manages the mapping of the logical name and physical name of the ontologies. • Identical ⇒ Equivalent This module deals with the name database to insert, delete, modify and query the logical and physical names of the The relationship sub-module is responsible for tracking these ontologies. These requests come from actions and predicates implications and correctly answering the queries from the module and ontology relationship module. clients about the relationship even if the implications are deeply nested. 4.2.2 Relationship between Ontologies Six relations are defined between ontologies in the 4.2.3 Registration with DF specification: Extension, Identical, Equivalent, Directory Facilitator, or DF, is a yellow page directory service Weakly-Translatable, Strongly-Translatable and of agents in an application domain defined in the Agent Approx-Translatable. These relationships of the Management specification. It stores the agent description and ontologies are expressed in the ontol-relationship service descriptions of the agents and answers queries about predicate with the form of (ontol-relationship them from other agents. Agent must register with the DF in ). This sub-module is responsible for order to advertise the capabilities of itself. This sub-module managing and maintaining the ontology relationship database. prepares the agent description and service descriptions of the It inserts, deletes, modifies and answers the relationship OA and registers with the DF using the FIPA-request according to the request coming from the actions and interaction protocol when the OA is activated. (Registration predicates sub-module and naming and referring ontologies with AMS, which is a white page directory service of the agent sub-module. Table 3 below explains the definition of the platform, is also a mandatory step of initializing the agent and relations between two ontologies. thus automatically handled by the agent communications library.) Table 3. Relations between ontologies 4.2.4 Actions and Predicates This sub-module handles the actions and predicates used in Relation Description the OA. There are two cases in terms of the actions and predicates that are handled here. Extension Ontology O1 extends the ontology O2. (1) OKBC-related actions and predicates In this case, this module calls OKBC interface to process the Identical Ontologies O1 and O2 are actions and predicates. identical. (2) Actions about ontology name and relationship between Equivalent Ontologies O1 and O2 are ontologies equivalent. If the action is about the ontology name or the relationship main loop of the OA evaluates the interaction protocol handler between the ontologies, naming and referring sub-module and closure to control the conversations between the OA and the ontology relationship sub-modules are called to process the client agents or the DF according to the specified interaction request. protocol. (Note that closures are heavily used everywhere in the program in general.) The actions include assert, retract, atomic-sequence from the FIPA-ontol-service-ontology, and inform, 5. DEMONSTRATION APPLICATION request, query-if, query-ref, agree and cancel from The purpose of the demonstration application of OA is to the standard communicative act library. The translate identify the strengths and weaknesses of the OA and its client action of the FIPA-ontol-service-ontology is not agents that constitute the real-world applications. Web-based implemented. This is the only feature that is not implemented on-line shopping mall was selected as such a practical inside the specification. The OA registers with the DF application. Comtec’s business partner, Intercraft Corporation expressing that it is unable to process the translate action (http://www.intercraft.co.jp/), has developed an on-line from one ontology to another. shopping application that is called Gumbo Note that the basic policy of FIPA about the implementation (http://www.gumbo.ne.jp/). We received the source code from of the specification is that the developer can choose which Intercraft and developed a version of the application that subset of the document to implement and which part not to makes use of the ontology service, which is called Ontology implement, as far as the consistency of the behavior of the Gumbo. As a consequence, we could not only test the agent is maintained. The agent must properly register with DF Ontology Gumbo but also compare the performance of and AMS about its capabilities: which functions are Ontology Gumbo with the original Gumbo. The following implemented and which functions are not implemented. Figures 8 and 9 show the structure of the original Gumbo and (Some features, for example, which communicative acts the the modified part of Ontology Gumbo. Please note that agent understands, are not registered with DF. This problem Ontology Gumbo server is implemented as a client agent of the should be resolved in the future version of the FIPA OA. architecture.) It is a responsibility of the applications designers (or, maybe the responsibility of the agents themselves if the agents are intelligent enough) to identify the necessary features of the agents and integrate the multi- agents by asking the DF for the service description of the agents in order to achieve the interoperability of the agents and deploy the applications. The atomic-sequence action needs a special attention. This action introduces a transaction-like (i.e., the ones found in SQL RDB) sequence of actions, which is treated as if it was a single action. The result of the atomic-sequence action is strictly one of the two cases: (1) all actions in the sequence have been successfully done; or (2) none of the actions in the sequence has been committed. Like RDB transactions, the OA takes care about the consistency between before and after the Figure 8. Original Gumbo server atomic-sequence, and inside and outside of the atomic- sequence. Firstly, the OA maintains the transactions log of each action in the sequence and rollbacks to the previous state of the KB, which is just before the atomic-sequence is initiated, if one of the actions in the sequence fails by any reason. Secondly, while the sequence of the actions is processed, the OA provides a virtual view of the state of the KB, which is just before the atomic-sequence is commenced, to other transactions so that outside agents cannot see the interim, possibly inconsistent, stage of the sequence. The OA commits the changes made by the sequence of actions if all of the actions in the sequence have been successfully completed without an error. 4.2.5 Interaction Protocols Figure 9. Ontology Gumbo server (part) This sub-module generates function closures that process the specified interaction protocols. In the OA, FIPA-request and By developing the demonstration application, firstly, we FIPA-query are the only two interaction protocols used. The wanted to know how easily an existing application could be modified to become the ontology client agent that utilizes the between the original and Ontology Gumbo systems when new OA. Then we have tested both original and Ontology Gumbo schema had to be added and the unified end-user view must be systems in terms of resource (CPU, memory, network etc.) presented. This could be partly because the developer was an utilization, response time, ease of systems modification such Oracle specialist and new to ontology; partly because the task as adding and removing database schemata, and fault tolerance. of integrating multiple database schemata was not appropriate Here we report some of the results. for the OA. 5.1 Development of the Demonstration 5.2 Run-Time Performance Comparison Application We have compared the run-time performance of the original The development of the demonstration application was made and Ontology Gumbo systems. The hardware and software by a programmer who had a pretty good knowledge on Oracle, configuration is as follows: Perl, Apache and Kawa, but did not hear anything about z Ontology Agent and OKBC server – Sun Ultra 5 ontology. The following Table 4 summarizes hours that 270MHz UltraSPARC IIi processor, 256MB memory, actually took for the programmer to modify the original 4.3GB disk, Solaris 2.6, JDK 1.2.2, OA, OKBC and TKB Gumbo to support the ontology service as a client agent of the OA. # of lines indicates modified or added number of lines in z Database and web server – Sun Ultra 5 the program code. 270MHz UltraSPARC IIi processor, 256MB memory, 4.3GB disk, Solaris 2.6, JDK 1.2.2, Oracle 8.0.5, Apache 1.3.9, Perl 5.005_03, original and Ontology Gumbo Table 4. Development hours z Gumbo client – PC Work Details Hours # of 233MHz Pentium MMX processor, 64MB memory, Items lines 4.3GB disk, Windows 98, Netscape Navigator 4.7, Prepara- Study on ontology 15.0 Internet Explorer 5 tion Setting up the development 3.0 z Gumbo client – Apple iMac environment 333MHz PowerPC G3 processor, 192MB memory, 6.4GB Creating Abstraction of the schema and 6.0 Aaa disk, Mac OS 9, Netscape Navigator 4.7, Internet the programming logic aaaa aaa Explorer 4.5 ontology Description of the ontology 3.0 219 z Gumbo client – Sun Ultra 5 Japanese characters processing 0.5 13 270MHz UltraSPARC IIi processor, 256MB memory, 4.3GB disk, Solaris 2.6, Netscape Navigator 4.7 Assertion of the ontology 0.5 These machines were connected to a closed 10Base-T LAN. Gumbo CGI interface 3.0 57 Typical end-user procedures of browsing a product catalog ontology OA interface 4.0 149 were timed for the combinations of OS, browsers, with/without client pictures and with/without ontology service. The data was not CGI Ontology client interface 2.0 70 successfully acquired for the Netscape Navigator 4.7 on Mac modifica- Utilizing the ontology 1.5 96 due to unstable Java Runtime Environment. Figure10 tion displays the results. Total 38.50 604 Although Gumbo is not a very big system (total number of lines: 16144), which offers just minimal functionalities of the on-line shopping mall, it took less than one person-week to change it to use the ontology agent. Please note that half of the time is spent by preparation. It would not take this much if the same person does the similar task. However, it should be also noted that advantage of having explicit and external ontology over implicit, internal and hard-coded ontology (database schema) was not made clear with such a small-sized applications. For example, there was no significant difference1 in terms of the development time 1 A reviewer suggested to compare the figures. Unfortunately, Figure 10. Gumbo performance comparison the record was lost and we are sorry we cannot present the exact numbers. As shown in the chart, overhead of using the ontology service immediately upon the release of the source code in October often exceeds ten seconds. One of the reasons of the bad 1999 and several key evaluation results were lost or not performance is that most of the Java optimization options had recorded. Anyway, we believe the technology of the ontology to be turned off in order to avoid the nasty bugs related to the service, which combines the proven power of OKBC and optimization (JIT compiler, native thread etc.) standard FIPA specifications, must be fully exploited in the real-world application in order to facilitate the advanced 6. FUTURE WORKS AND CONCLUSIONS knowledge sharing among the computers and the human Agentcities project (http://www.agentcities.org/) is a beings. worldwide initiative designed to help realize the commercial and research potential of agent-based applications. The 7. ACKNOWLEDGMENTS objective is to construct a worldwide network of agent The authors acknowledge Information-technology Promotion platforms based on the FIPA standard. Each platform, which is Agency of Japan (IPA) for funding the development of FIPA 97 called a City, will be supported by different organizations agent platform (Advanced Information Promotion Assistance around the world and host diverse populations of agents that Software Enrichment and Cultivation Project, under the are able to access each other's services. Communication contract 9JOUGIOUDAI569GOU) and the development of FIPA Technologies committed to take part in the project to host the 98 Ontology Service (Next Generation Digital Technology Sendai City, where the office is located, based on the Comtec Applications and Basic Foundations Support Technologies Agent Platform and the Ontology Agent. However, in order to Development Project, under the contract host the city platform and to be able to connect to other cities, 10JOUGIOUDAI908GOU). We also thank Artificial we have to work on some major update of the code because Intelligence Center of SRI International and Knowledge current platform is based on FIPA 97 and FIPA 98 Systems Laboratory of Stanford University for their OKBC specifications. Currently (as of April, 2001), FIPA has specification and implementation. The demonstration published most of the specifications as Experimental status, application would not have been made possible without the which means that the experimental implementations and the great courtesy of the Intercraft Corporation that developed the interoperability trials of the implementations by different original Gumbo system and kindly assisted us to build the developers are encouraged in order to promote the Ontology Gumbo. Last but by no means least, our special specifications to the Standard status. thanks to 1998 FIPA Technical Committee C members led by Agentcities project is a great motivation for us to update the the chair Fabio Bellifemine of CSELT, and general membership platform and add the following features to the platform: of FIPA that contributed to discuss and publish the Ontology z HTTP transport of the agent communications; Service Specification. z XML representation of the ACL and SL; 8. REFERENCES z Gateway between the HTTP/XML world and existing [1] Bothner, P. The Kawa Scheme System. IIOP/S-expression world; http://www.gnu.org/software/kawa/ z Deploy the Ontology Agent on top of the revised platform; and [2] Chaudhri, V. K., Farquhar, A., Fikes, R., Karp, P. D., and Rice, J. P. Open Knowledge Base Connectivity 2.0. z Performance tuning of overall platform. Technical Report KSL-98-06, Stanford University KSL, In addition, we are committed to provide other cities with the 1998. http://www.ai.sri.com/~okbc/spec.html ontology service, which is based on, as far as we know, the [3] FIPA. FIPA0006: FIPA 98 Specification Part 12: only implementation of the FIPA Ontology Service Ontology Service. http://www.fipa.org/specs/fipa00006/ specification. It is expected that by utilizing the ontology service, heterogeneous agents developed by different [4] FIPA. FIPA0086: FIPA Ontology Service Specification. participants and located in different cities will be able to share http://www.fipa.org/specs/fipa00086/ a common ontology to establish a basis for a meaningful [5] Intelligent Agent Society of Japan. Japanese translation conversation. of FIPA 98 Specification Part 12: Ontology Service. In conclusion, we have presented our experience of http://fipa.comtec.co.jp/fipatrans/j98v1p12.PDF implementing FIPA Ontology Service specification. It is our [6] Suguri, H. et al. Comtec Agent Platform. big regret that we have not published a paper on the software http://fipa.comtec.co.jp/ap/