=Paper=
{{Paper
|id=Vol-66/paper-13
|storemode=property
|title=Modeling Utility Ontologies in Agentcities with a Collaborative Approach
|pdfUrl=https://ceur-ws.org/Vol-66/oas02-13.pdf
|volume=Vol-66
|authors=Luigi Ceccaroni and Myriam Ribiere
}}
==Modeling Utility Ontologies in Agentcities with a Collaborative Approach==
https://ceur-ws.org/Vol-66/oas02-13.pdf
Modeling Utility Ontologies in Agentcities with a
Collaborative Approach
Luigi Ceccaroni Myriam Ribiere
Fujitsu Laboratories of America Motorola Laboratories
595 Lawrence Expressway Espace technologique Saint Aubin
Sunnyvale, CA 94085, USA 91193 Gif-sur-Yvette Cedex, France
+1 408 530 4563 +33 (0)1 69 35 48 39
lc@fla.fujitsu.com myriam.ribiere@crm.mot.com
ABSTRACT constructing an open, distributed network of platforms hosting
This paper presents experiences about the modeling and diverse agents and services. The ultimate aim of Agentcities is to
implementation of utility ontologies used within the Agentcities enable the dynamic, intelligent and autonomous composition of
initiative. Utility ontologies include domain-independent concepts services to achieve user and business goals. The Agentcities.RTD
which most services developed within the project use. Ontology project includes 14 partners from academia and industry. Each
building was carried out collaboratively among very different partner deploys an agent platform, and agents and services based
partners from industry and academia. The application domain of on that platform. The communication among these services has
the ontologies is an open, dynamic test-bed for agent deployment part of its semantic grounding in a series of utility ontologies,
and they are explicitly designed to be shared by most services which model common, general concepts. Besides the utility
created within this environment. The ontologies are implemented ontologies, partners collaboratively designed several domain
in the DAML+OIL knowledge-representation language and a ontologies (which will be shared by and used within services) for
summary is given of the tools which currently let the user manage the following domains: accommodation, geographic information,
this language at a high level. rating, restaurant, shows, transport and weather. A general
service-interoperability ontology is also being modeled.
Keywords 2. UTILITY ONTOLOGIES
Ontologies, Agentcities, Experimentation, DAML+OIL.
In January 2002, a group of partners from the Agentcities.RTD
project began modeling domain-independent concepts in the form
1. INTRODUCTION of ontologies to be used by most services developed within the
Ontologies are being developed in AI to facilitate knowledge project. Identifying, descriptive and functional features of the four
sharing and reuse. In general, ontologies can provide: (1) a shared ontologies finally modeled (address, contact details, price,
and common understanding of a knowledge domain that can be calendar) are presented in Table 1. During a meeting in February
communicated among agents and application systems; (2) an 2002, DAML+OIL1 was chosen as the ontology modeling
explicit conceptualization that describes the semantics of the data; language, while FIPA-SL2 was chosen as the content language.
(3) a basis for Web Services markup, facilitating their Although the DAML+OIL language is at the center of current
composition and mapping [3] [6]. Ontologies are considered to be research on the Semantic Web, there are drawbacks in using it: (1)
a critical part of the work on the Semantic Web, which will allow the constant evolution of the language within the DAML project
software agents to communicate among themselves in meaningful (the language is not yet stable); (2) available ontology editing
ways [1], and attract attention not only from academic disciplines tools (see section 2.2) are not satisfactory and do not handle all
such as computer science, information science and artificial the features of the language, which makes them not apt to be used
intelligence, but also from industries as diverse as the high-tech, for the complete cycle of ontology design and implementation; (3)
financial, medical, educational and environmental sectors [4]. there is not much documentation on experience and good
practices in using DAML+OIL to build usable and reusable
To obtain a shared and common understanding of a domain, a ontologies.
collaborative effort is necessary, involving ontology architects and
domain experts; however, there are not many initiatives that have
used and documented collaboration in building ontologies.
2.1 Knowledge acquisition
International standards were taken into accounts when modeling
Small-scale collaborations reflecting diverse viewpoints and
the utility ontologies, though none of them was sufficiently
backgrounds for the design of specific-domain ontologies exist
concise to be fully adopted by the short-term EU Agentcities
(such as [5] and [2]), but participation in large ontology project is
project. The ontology specifications developed within Agentcities
typically limited to academics coming from an AI background.
The European Commission funded Agentcities.RTD project is 1
See [http://www.daml.org/language/].
part of a worldwide initiative [8] designed to help and realize the 2
commercial and research potential of agent based applications by See [http://www.fipa.org/specs/fipa00008/].
therefore differ from the ontologies implied by existing standards, development of the utility ontologies proceeds with an eye
but they are in no way intended to create separate definitions for towards ensuring that their future users will find their
concepts defined by standards bodies. We indeed are working characterizations to be sufficiently correct, clear and concise.
towards a convergence of the ContactDetails ontology with the Ontological commitment is thus an integral aspect of ontological
vCard standard3 and of the Calendar ontology with the iCalendar engineering [5] in the Agentcities.RTD project.
standard4.
Collaborative development of ontologies in Agentcities was
2.2 Ontology editors carried out through both face-to-face meetings and remote
There are, at the moment, a number of more or less generic editors communication (email and IRC sessions). No satisfactory on-line
to create and manage ontologies, but just a few of them can tool or environment exists that supports the DAML+OIL language
manage the DAML+OIL language. To the best of our knowledge, and collaborative development.
there are only two ways to carry out this management process at a
xsd: integer
high level, neither of which is very practical or satisfactory:
1. OilEd and Protégé-2000
range
o Creating: any program that can save files as RDFS, for
example (with some limitations) the OilEd5 editor.
DatatypeProperty
o Editing: Protégé-20006 with the Ontoviz graphical
hour
visualization plug-in (or other equivalent plug-ins).
o Exporting: OilEd, which (with some limitations) can import
RDFS files that have been edited in Protégé-2000. onProperty
2. Ontolingua and Chimaera
Class DatatypeProperty
o Creating: any program that can save files as DAML+OIL. Duration onProperty minute
o Editing: Ontolingua environment. To import a DAML+OIL
file into the KIF-based Ontolingua, it is necessary to use onProperty range
Chimaera7.
o Exporting: Chimaera (with some limitations and a user DatatypeProperty
xsd: integer
unfriendly interface). second
We did not extensively test yet any ontology consistency-checking
and reasoning tools, available for these methodologies, such as
range
JTP and FaCT.
In conclusion, we acknowledge that, if we had not required an
XML-based language as the ontology language, an alternative, xsd: integer
more practical solution to ontology management would have been
to use only the Ontolingua environment and to work with KIF
ontologies, thus avoiding a number of language translations. Class
subClassOf TimeUnit subClassOf
subClassOf
3. COLLABORATIVE APPROACH
Researchers taking part in the Agentcities.RTD project come from Class Class Class
very different areas of study and have different perspectives on Second Minute Hour
ontology modeling, but, significantly, they pledged to adopt the
same ontological commitment. That is, they agree to adopt
common, predefined ontologies when communicating about a range range range
domain of interest or to express general categories, even if they do
not completely agree on the modeling behind the ontological ObjectProperty ObjectProperty ObjectProperty
representations. Where ontological commitment is lacking, it is second minute hour
difficult to converse clearly about a domain and to benefit from
knowledge representations developed by others. The ongoing
onProperty
3
vCard 3 is defined by RFC 2426 [http://www.imc.org/pdi/].
4 Class
iCalendar is defined by RFC 2445 [http://www.imc.org/pdi/]. onProperty
Duration onProperty
5
See [http://oiled.man.ac.uk/index.shtml].
6 Figure 1. Methods of representing the range of properties.
See [http://protege.stanford.edu/].
7
See [http://www.ksl.stanford.edu/software/chimaera/].
3.1 Methodology
The construction of ontologies is a time-consuming and complex
task, in particular during the conceptualization phase, when
developers define the set of concepts and their relations by an
intermediate representation often based on tabular and graphical
notations. A common graphical representation has to be agreed
and a common media for the interchange of proposals and a
decision system to overcome disagreements have to be chosen.
In Agentcities, during the conceptualization phase, the following
issues had to be dealt with. We acknowledge that the very
classification of these issues is subjective and that it is not the
only possible one.
Data types versus classes. As shown in Figure 1, there are two
ways of representing the range of properties: as a predefined data
type (for example, integer; above in the figure) or as a class (for
example, subclass of TimeUnit; below in the figure). Using classes
is semantically richer, but more complex.
Individuals versus classes. There are two ways of representing the
elements of a class: as individuals or as subclasses. Using classes
is semantically richer and makes the extension of ontology easier.
Even if more complex, in general the use of classes was preferred.
Properties of properties. As shown in Figure 2, there are 3 ways
of representing properties of other properties. In the example, we
want to represent the kind (e.g., personal or business) of
properties of the ContactDetails class, such as phone number and
pager8. One possible way to achieve this is to define a property for
each, which has as the range a common concept called
ContactDetailType (top part of the figure). In this option, as well
as in the next one, we acknowledge the fact that the notions of
personal/business and private/work are common to many
concepts, and we exploit it to simplify the design. The
ContactDetailType class has thus three individuals,
PersonalWork, PersonalPrivate and Business, which are the
possible values of the range of the phoneNumberType and
pagerType properties (or, in other terms, the possible types of
phoneNumber and pager). A second possibility, to avoid defining
a property of a property (which some languages do not allow), is
to introduce bridge classes as the range of phoneNumber and
pager (central part of the figure). In our modeling, these first 2
approaches are semantically equivalent and interchangeable. A
third possibility is to have specific subclasses, representing the
different type for each property of ContactDetails (bottom part of
the figure). For example, for the PhoneNumber class, we define
explicitly all the different subclasses: PhoneNumberBusiness,
PhoneNumberPersonalWork, and PhoneNumberPersonalPrivate. In
general, we think that the creation of additional classes is
preferable only in the case in which the resultant representation is
semantically richer.
Cultural differences. Even though the concepts included in the
utility ontologies are very general, the differences in the cultural
background of each partner caused some discrepancies in the
design of the ontologies, in particular, in the case of the address
ontology. Apart from the most general level, different countries
use different conventions to express an address and thus
generalization is not easy.
8
Other (not shown) properties of ContactDetails which behave in
the same way are: mobile phone number, web page, fax number,
email, and other. Two other properties of ContactDetails which
have a different behavior are: name and address. Figure 2. Methods of representing properties of properties.
Table 1. Features of the four utility ontologies.
Address Contact details Price Calendar
Name Address.daml ContactDetails.daml Price.daml Calendar.daml
Subject Management of most Management of contact Management of prices. Management of events
types of addresses of details for a person or in time.
common use. for a business.
List of higher-level Address, ContactDetails, Price, PriceRange Calendar, Date,
concepts BuildingSubDivisionType, ContactDetailType, Name DayOfWeek, Duration,
PublicPlace Time, TimeFormat
Integrated ontologies none Address ontology none none
Number of classes 13 5 6 6
Number of instances 0 3 0 9
Number of properties 18 27 4 15
Number of class at 1st, 3, 10, 0 3, 2, 0 2, 4, 0 6, 0, 0
2nd and 3rd level
Number of class leaves 10 4 5 6
Average branching 3 1 2 0
factor
Average depth 2 1 2 1
Highest depth level 2 2 2 1
4. CONCLUSIONS [2] Ceccaroni, L. OntoWEDSS - An Ontology-based
Environmental Decision-Support System for the management
Four utility ontologies for the common, general concepts of of Wastewater treatment plants. Ph.D. thesis, Universitat
Address, Contact Details, Price and Calendar have been created.
These ontologies have been modeled through a collaborative
[3] Fensel, D., Horrocks, I., Van Harmelen, F., Decker, S.,
Erdmann, M., and Klein, M. OIL in a nutshell. In R. Dieng et
effort among several partners of the EU Agentcities.RTD project.
al. (editors) Knowledge Acquisition, Modeling, and
The modeling process took into account all the available,
Management, Proceedings of the European Knowledge
compatible indications on methodology coming from the ontology
Acquisition Conference (EKAW2000), Lecture Notes in
community and this paper enriches those indications through
Artificial Intelligence (LNAI) , Springer-Verlag, pp. 1-16,
extensive practical experience. The utility ontologies described
2000.
here are the manifestation of a shared understanding and will be
used, within the Agentcities network, as part of the semantic [4] Gruninger, M., and Lee, J. Ontology applications and
grounding for the communication among Web Services. The design. In Communications of the ACM, 45, 2, pp. 39-41,
implementation language of the ontologies is DAML+OIL 2002.
[5] Holsapple, C.W., and Joshi, K.D. A collaborative approach
5. ACKNOWLEDGMENTS to ontology design. In Communications of the ACM, 45, 2,
The authors wish to extend their thanks to the other partners in the pp. 42-47, 2002.
EU Agentcities.RTD project involved in the modeling phase, and
to Jonathan Dale for the feedback after having read a preliminary
[6] McIlraith, S.A., Son, T.C., and Zeng, H. Mobilizing the
Semantic Web with DAML-Enabled Web Services. In
version of this paper. The research described in this paper is partly
Proceedings of Autonomous Agents 2001 – Ontologies in
supported by the EC project Agentcities.RTD (IST-2000-28385).
Agent Systems (OAS 2001) workshop (Montreal, Canada),
The opinions expressed in this paper are those of the authors and
pp. 1-11, 2001.
are not necessarily those of the EU Agentcities.RTD partners.
[7] Uschold, M., and Gruninger, M. Ontologies: principles,
6. REFERENCES methods and applications. In The Knowledge Engineering
Review, 11, 2, pp. 93-136, 1996.
[1] Berners-Lee, T., Hendler, J., and Lassila, O. The Semantic
Web. In Scientific American, 284, 5, pp. 34-43, 2001. [8] Willmott, S., Dale, J., Burg, B., Charlton, P., and O’Brien, P.
Agentcities: A Worldwide Open Agent Network. In The
Agentlink Newsletter, 8, pp. 13-15, 2001.