=Paper=
{{Paper
|id=Vol-52/paper-9
|storemode=property
|title=Implementation of FIPA Ontology Service
|pdfUrl=https://ceur-ws.org/Vol-52/oas01-suguri.pdf
|volume=Vol-52
}}
==Implementation of FIPA Ontology Service==
https://ceur-ws.org/Vol-52/oas01-suguri.pdf
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/