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.