Towards an OWL-formalization of the Resource

Event Agent Business Domain Ontology

Frederik Gailly⋆ and Geert Poels

Ghent UniversityManagement Informatics Research Unit

Hoveniersberg 24, 9000 GentFrederik.Gailly@Ugent.be, Geert.Poels@Ugent.be

Abstract. Business domain ontologies offer great opportunities for fa-cilitating communication between people in business, for improving theenterprise system engineering processes and for creating interoperabilitybetween enterprise systems. However despite these opportunities, theiruse in practice is still limited. This can be partly attributed to the lackof formal representation of these ontologies.This paper analyses current formalizations of the Resource Event Agentbusiness domain ontology (REA-ontology) and investigates how this for-malizations can be improved. Our approach recognises the opportunitiesthat the conceptual modelling and database field can offer for ontologyengineering and as a consequence a UML conceptualization of the busi-ness domain ontology is used as starting point of the formalization. Basedon the transformation guidelines from UML to OWL and the current for-malization of OWL we present some transformation dilemmas. It is ourbelieve that these formalization problems are not unique to business do-main ontologies and that other domain ontologies can also benefit fromstandard solutions to these formalization problems.

1 Problem and Context

Business domain ontologies offer great opportunities for creating interoperabilitybetween enterprise systems. The successful application depends on the quality ofthe business domain ontology. Important ontological quality factors are reusabil-ity, reliability, shareability, portability and interoperability[1, 2]. In our view abusiness domain ontology with a strong theoretical basis which is engineeredfollowing a good methodology resulting in a proper formalisation will be of amuch higher quality. This in turn will lead to more and successful applications.

The last decade different business domain ontologies (Tove[3], Enterprise On-tology[4], REA Business Ontology[5], E3 value Ontology[6] and Business ModelOntology[7]) have been proposed. The developers of these business domain on-tologies have different scientific backgrounds and this is shown in the differenttheoretical backgrounds of the ontologies. The creators of Tove and the Enter-prise Ontology have an artificial intelligence background and the development

⋆ Corresponding Author

of their ontologies gave them a more precise understanding of the ontology engi-neering process. The other ontologies share a more business-oriented focus. TheBusiness Model Ontology is based on the balanced scorecard and has a strategicfocus. The E3 value ontology is developed to support the requirements engineer-ing process of an e-commerce project and should make sure that economic valueis created. The REA-business domain ontology has a strong theoretical basis inaccounting and micro-economics, and will be further described in detail later inthis paper.

Most of these domain ontologies have a strong theoretical basis but lack a for-mal description that can be used in practice. Tove and the Enterprise Ontologyare both formalized by the Ontolingua framework but to our knowledge this hasnot lead to much usage in practice. For the development of a formal representa-tion of the Business Model Ontology[7] and the REA business domain ontology[8] Protege 2000 was used. With the release of the OWL plug-in for Protege thishas also resulted in an OWL formalization of these business domain ontologies.The E3 value ontology is not formalized and according to Gordijn ([6]) this isnot required because of the mainly communication focus of the ontology.

In [7] the benefits of formalizing the ontology are recognized. In the caseof the Business Model Ontology the formalisation has led to a more precisespecification of the business domain constructs and relations [9] and the for-malization also creates a lot of opportunities in business management research[10]. The Inforge Group of the University of Lausanne is currently investigatinghow their formalized business model ontology can support new methods andcomputer-tools for diverse fields as business model design, business strategy andInformation Technology/ Information Systems alignment.

A formalization of the conceptualization of the application domain helps thedevelopers to analyse their proposed ontology by comparing it with reality andcan more easily expose critical issues. Formal languages describe the meaning ofknowledge precisely and this supports automatic reasoning, which can be usedfor checking the consistency of the ontology[11]. A formal description also makesit easier to map different ontologies and find similarities between ontologies. Gen-erally a formal description will improve the acceptance of the business domainontology and will facilitate the development of applications.

The Resource Event Agent business ontology (REA-ontology)[5] is anotherbusiness domain ontology that offers great possibilities because of its strongtheoretical basis and its unique structural characteristics. Its foundation in mi-croeconomics(Theory of the Firm), strategic concepts (Porter’s Value Chain[12])and basic accounting principles holds great promises for enterprise system designand creating interoperability between enterprise systems. The accounting back-ground of the REA-ontology is evidenced by its core construct: economic duality.This means that each increment event in the business’s resources is linked with acorresponding decrement event. This constraint thus ”forces the business analystor designer to consider explicitly the causal links between events and resources[13]” and should lead to more complete business models when the REA businessdomain ontology is used during enterprise system design.

Unfortunately unlike the Business Model Ontology, the REA-ontology is un-derspecified as an ontology. The terminology of the constructs of the REA-ontology is sometimes inconsistent and confusing [14]. The proposed definitions,relations and constraints need to be converted into a formal language to discoverinconsistencies and to analyze operational use[15]. A more formal conceptualiza-tion in an ontology language will improve the definition of the constructs andwill prove that the REA-ontology can offer real support for enterprise systemdesign and creating interoperability between enterprise systems. The machinereadable REA-ontology can be used to develop tools for business modelling andcan offer support for supply chain collaboration [16].

In this paper we take the first step towards developing a formal representa-tion of the REA-ontology in OWL. In the next section the current specification,conceptualization, formalization and implementations of the REA business do-main ontology are described. In the third sections this current description andsome existing formalization guidelines are used to discuss some ’UML to OWLtransformations’ that can be used to formalise the REA-ontology. Finally, thelast section outlines the conclusions and our future research.

2 Existing Resources and Past Work

The formalization of the REA business domain ontology must be the resultof a structured ontology development process. Our approach is based on theMethontology Framework developed by [17] but mainly focuses on the develop-ment oriented activities. The management and support activities that supportthe ontology development process are also important and will surely improvethe development process but they are not the main focus of this paper. In thenext subsections the current specification, conceptualization, formalization andimplementation of the REA business domain ontology is described.

2.1 Specification REA Business Domain ontology

For almost twenty years the REA model was widely used as an educationalinstrument for teaching business students how to design accounting databases[18], while its use in system development practice was limited to a few com-panies[19]. Recently there has been a remarkable increase in researchers’ andpractitioners’ interest in the model because of two reasons. First, the REAmodel developers were involved in a number of international standardizationefforts for e-collaboration systems (e.g. ISO Open-EDI initiative, UN/CEFACT,OAG, eBTWG). This participation has resulted in the adoption of (parts of)the REA model as a business process ontology in the UMM business processand information model construction methodology [20] and the ECIMF systeminteroperability enabling methodology [21]. Second, the REA model has beenproposed as a theoretical basis for the reference models that underlie ERP sys-tems [22]. Both developments are witnesses of the REA model’s importance inthe current and future enterprise systems landscape.

The original REA-model was developed by McCarthy in 1982 and presentedas a semantic model for the development of accounting systems[23]. Over theyears McCarthy and Geerts changed focus and started to consider REA as abusiness domain ontology, which resulted in extensions to the basic REA model.These include the modelling of accounting phenomena at different levels of ab-straction (value chain, process and task) and additional ontological primitivesand axioms(commitment events, type images)[5].

2.2 Conceptualization of the REA Business Domain ontology

For the description of the REA-ontology the recent work of Geerts and McCarthycan be used[15, 24]. In these papers REA-ontology constructs and the relationsbetween them are presented by means of ER diagrams or UML class diagrams.Table 1 summarises the most important definitions.

Table 1. REA-ontology concepts definitions[5, 15, 24]

REA-construct Definition

Business Process a collection of activities that takes one or more kindsof input and creates an output that is of value to thecustomer [25].

Economic Event Economic Events represent increments or decrements ofthe value of the resources. Economic events in the ex-change processes represent transfer of control of an eco-nomic resource from one economic agent to another,where one agent provides other agent certain rights forthe resource. Economic events in the conversion processesrepresent changes of the features of the resources.

Business Event a significant occurrence in time that enterprise manage-ment would like to plan, control or evaluate.

The REA business ontology exists of a three-level architecture for presentingeconomic activities. Based on the work of [12] and [26] an enterprise is repre-sented by a value chain, which is seen as an network of business processes [27].A business process is in turn an aggregate of Economic Events.

According to the REA-ontology each economic event is part of a pattern ofrelations between three kind of objects that can be identified in every economicexchange or conversion process: economic resources, economic agents and eco-nomic events. Each economic resource is linked with an economic event thatcauses its inflow or outflow (stock flow). Furthermore every economic event thatresults in a resource inflow (e.g. a purchase) must be paired by an event thatresults in a resource outflow (e.g. a cash disbursement), and vice versa (dual-ity). The participation relationship describes the agents involved in an EconomicEvent. This simple ontological pattern forms the basis of the REA-ontology andis derived from McCarthy’s original REA model(figure 1)[23].

Fig. 1. REA model [23]

However to accomplish the economic events (economic exchange or conver-sion) an ordered sequence of actions, called business events, are needed. ”Busi-ness Events illustrate the task-decomposition structure of the workflow neededto accomplish the paired Economic Events ([15], p.8).” The relations between thethree levels of modelling abstractions (value chain, business process, economicevent) are shown in the Three-Level Architecture Model (Fig. 2). The formaliza-tion presented in this paper addresses only the middle layer of this architecture.The formalization of the other layers is considered as future work.

Fig. 2. Three-Level Architecture Model based on Geerts and McCarthy[15]

The basic REA-model shown in Figure 1 has been extended with additionalconcepts and axioms. One of the extensions is the commitment concept. Basedon Ijiri the REA-ontology defines a commitment ”as an agreement to executean economic event in a well defined future that will result in either an increaseof resources or a decrease of resources”([28], p. 130). The commitment conceptis linked with economic event by a ’fulfill’ association. Similar to the dualityrelationship between economic events a reciprocal relationship is defined be-tween commitments. A reciprocal commitment establishes an economic agree-ment which can be of two type: a schedule (for conversion processes) or a contract(for exchange processes) [15].

The original REA paper ([23]) also expressed the need for an additionaleconomic claim construct for capturing temporal(like payables) or more enduring(like loans) imbalances in duality relationships. If a decision is made to reify theduality imbalance, then two relationships become needed: (1) from the claim tothe economic event that materializes it, and (2) from the claim to the economicevent that settles it [13].

So far the presented business domain ontology only consists of past, presentand future economic phenomena. This operational infrastructure is extendedwith a knowledge infrastructure that conceptualizes the abstract phenomenathat characterize the actual economic phenomena [29]. The abstraction usedin the REA business ontology is typification, which captures descriptions thatapply to a group of actual phenomena. This abstraction adds a knowledge layerfor planning and control above the operational infrastructure.

The knowledge infrastructure contains the following types of abstract classes:Economic Resource Type, Economic Event Type and Economic Agent Type.These classes can be associated with the type image relations: ’policies’ and’standards’. In the REA business ontology ’policies’ are defined as abstractionsthat restrict the legal configurations of the actual phenomena and ’standards’define blueprints for the actual phenomena [15].

The knowledge and operational infrastructure interact by the economic com-mitment concept as this is both an operational and abstract phenomena. Com-mitments promise to execute economic events in the future and their specifica-tion is abstract because usually commitments consists of type-level designationof expected behaviour [15].

Figure 3 presents a summary overview of the operational and knowledge in-frastructure of the REA ontology at the business process level in a UML classdiagram. It is based on the different class diagrams presented in the Geerts andMcCarthy papers and it will be used for the development of the formal represen-tation of the REA-ontology. Figure 3 contains also the different specialisations ofthe basic REA constructs. Important to notice is that not only the entities arefurther specialized but also the relationships (represented by associations andassociation classes).

Fig. 3. UML Class-diagram Business Process Layer REA-ontology

2.3 Current formalization REA business domain ontology

Currently the formalization of the REA business domain ontology is very limited.In the papers of Geerts and McCarthy UML class diagrams are used for thedescription of the relations between the concepts. The ontological primitives andaxioms are only described in text but are not formalized in a formal language.

Geerts explored how XML technologies can be used for the operationalizationof the REA enterprise ontology [30]. XML schema is used to formalize parts ofthe REA-ontology. Geerts chooses XML-schema because of the wide acceptanceof this language but this will limit the use in practice of the REA-ontology andthe use of ontology languages like RDF(S) and OWL offer far more opportuni-ties. The semantic web layers proposed by W3C also indicate that XML / XMLSchema layer is there to make sure that the semantic web definitions are com-patible with XML standards. As a consequence XML-schema is not consideredas an ontology language and the available ontology languages like OWL andRDF(S) are far more suited to capture a business domain ontology.

However there were some efforts from other researchers to formalize the REAontology. Borch et al.([31]) also formalised the REA-model with XML. The rea-son for choosing XML is similar to Geerts, the formalised REA-model is used ona Java platform where XML is widely supported by a range of transformation

and verification tools. However in the proposed application (confer infra) of theREA-model UML could also be used.

Bialecki was the only one that explored ontology languages and tools forthe formalisation of the REA ontology[8]. As part of the E-Commerce Integra-tion Meta-Framework project he formalized the REA-ontology with Protege andRDF(S). However his latest updates date from 2001 and the REA-ontology hasbeen subject to different changes since 2001. Furthermore Bialecki also encoun-tered some ’disputable issues’ and it is our intention to critical evaluate thechoices made in order to improve the formalisation of the REA business domainontology. In section 3 our approach is explained and we will also indicate howthis approach differs from Bialecki.

2.4 Current implementation of the REA business domain ontology

To our knowledge currently there is no implementation that uses the full REAbusiness domain ontology. However because the REA-model was originally de-signed to support the conceptual design of accounting information systems, theirare some applications in the software engineering context. Borch et al.([31]) usetheir XML formalization of the REA-model as a platform independent model(PIM) in the Model Driven Architecture (MDA) approach to software engineer-ing. The main contribution of their work is the exploration of the MDA conceptsin a domain specific context.

In the First International REA Technology Workshop (2004) a lot of re-searchers explored how the REA business domain ontology could be opera-tionalized. A lot of the proposed implementations were related to supply chainmanagement (SCM) and enterprise resource planning (ERP). Building businesssystems based on the REA business ontology can enhance the interoperabilityand adaptability of the system.

3 Formalization in OWL

In the ontology engineering field many different approaches are used for theformalization of an ontology. However, many authors have recently recognisedthe opportunities that the conceptual modelling and database field can offer forontology engineering. Conceptual modelling approaches have been designed togive a semantically rich description of the universe of discourse and ”could, atleast to some extent, handle the description of the conceptualisation that is thesubject of some ontology” ([32], p. 25).

In our approach we wish to use the UML class diagram presented in theprevious section as an intermediate for the formal representation of the ontol-ogy. The mapping between UML and OWL is based on the work of [33] whocompare UML with DAML and give some rules for the mapping between UMLand DAML. In our transformation we will use these rules as guidelines for themapping between the UML class diagram of the operational infrastructure ofthe REA-ontology and OWL. At this stage RDF(S) could also be used, but we

expect that in a later stage when additional constraints will incorporated, OWLwill offer the best solution.

In this research paper we will not present the whole formalization of theREA business domain ontology, but some formalization dilemmas we encoun-tered during our approach. The whole formalization saved as an Protege projectis available at http://users.ugent.be/∼fgailly/phd. Some of the transformationsfrom UML to OWL are very straightforward, but in other cases it is hard todetermine the most appropriate transformation. Table 2 gives some examplesof the straightforward transformations. UML classes were transformed in OWLclasses and for the specialisation of classes the OWL ’subClassOf’ construct wasused.

Table 2. Straightforward Transformations between REA ontology UML class diagramand OWL

According to the guidelines of [33] UML associations can be mapped intoobject properties, but during the formalization of the REA UML class diagramwe came across additional problems. Unlike the examples in [33] all associa-tions in the REA UML class diagram are bidirectional and as a consequencethe associations had to be replaced by two directed associations which can thenbe formalised with two inverse object properties (table 3). For the naming ofthe inverse object properties the Protege guidelines were followed. Every objectproperty was prefixed with the word ’has’ and his inverse object property wasprefixed with the word ’is’ and suffixed with ’of’. Our approach however re-mains under investigation and it could that be that formalizing an bidirectionalassociation as only one object property is sufficient.

Another problem is the use of association classes in the UML class diagramconceptualization. For the transformation of association classes two approachesare possible: (1) an association class can be considered as a sort of association andthus formalised as a ’subProperty’ or (2) the association class can be reified intoa UML class which can be formalised following the transformations presented

Table 3. Transformation dilemma REA ontology UML association and OWL

before (table 4). In our opinion both approaches are correct, but it might be thatthe ’object property’ concept is too limited to formalize an UML associationclass. Following the UML specification an association class has both associationand class properties, and the OWL object property concept supports some classproperties (specialization, ...) but to our knowledge not all (disjunct subclassassociations). Reifying the association class can be a quick solution to avoidthese shortcomings.

Table 4. Transformation dilemma REA ontology UML association class and OWL

During the formalization it also became clear that the current specificationand conceptualization of the REA business domain ontology is not sufficient.Geerts and McCarthy define associations (e.g. inflow, outflow, ...) that are infact specializations of another association (stock-flow). A good formalization ofthese type of associations require that also the association ends of these typeof associations are defined. This means that we must define which subclasses ofthe classes, that are part the more general association, can participate in thespecializations of the more general association. This problem clearly shows thatthe specification and conceptualization can benefit from a good formalization.

The so far presented transformations are not complete and additional prob-lems will arise when other parts of the REA business domain ontology are for-malized. The graphical representation will become more complex when moreconstructs and constraints are added and more complex mapping rules will beneeded. In future research we will further evaluate existing mapping rules andhow they can be used for the development of a formal representation of theREA-ontology. Finally, it is our intention to translate the mapping rules into anXSLT stylesheet which can be used for transforming the XMI representation ofthe UML diagrams into a representation in the target ontology representationlanguage.

4 Conclusion and Future Research

A correct formal representation of the REA-ontology offers great opportunitiesand will facilitate the operationalization of the REA-ontology. In this paper thetransformation rules from UML to OWL are applied on the REA business do-main ontology. It is shown that some transformations are not as straightforwardas expected and we also find some prove that the formalization of an ontologycan reveal shortcomings in the specification of the application domain ontology.

In future research the UML class diagram will be further expanded withthe business event specification of the REA-ontology. The REA-ontology alsocontains some additional constraints that are not incorporated in this paper andmust be added in future research. Probably OCL will be needed to model theconstraints in the UML class diagram and therefore it must be investigated howthese constraints can be translated in OWL. However it could be that basic UMLand OCL will not satisfy needs for representation of ontology concepts that areborrowed from Description Logic. Maybe the use of UML profiles can offer asolution or maybe basic UML needs to be extended with additional elements[33,34].

In this paper the main focus lies on the transformation from UML classdiagrams into an OWL representation. It is however our intention to improveevery step of the ontology development process and this in the specific case ofbusiness domain ontologies. It is our intention to compare, evaluate and improveevery existing business domain ontology and this should eventually result insuccessful applications.

References

1. Spyns, P., Meersman, R., Jarrar, M.: Data modeling versus Ontology engineering.SIGMOD record: Special Issue on Semantic Web and Data Management 31 (2002)12–17

2. Ushold, M., Gruninger, M.: Ontologies: Principles, Methods and Applications. TheKnowledge Engineering Review 11 (1996) 93–136

3. Fox, M.S., Gruninger, M.: Enterprise Modeling. AI Magazine 19 (1998) 109–121

4. Ushold, M., King, M., Moralee, S., Zorgios, Y.: The Enterprise Ontology. TheKnowledge Engineering Review: Special Issue on Putting Ontologies to Use 13(1998) 31–89

5. Geerts, G.L., McCarthy, W.E.: An Ontological Analysis of the Economic Primitivesof the Extended-REA Enterprise Information Architecture. International Jouralof Accounting Information Systems 3 (2002) 1–16

6. Gordijn, J.: Value based requirements engineering: Exploring innovative e-commerce ideas. PhD thesis, Vrije Universiteit Amsterdam (2002)

7. Osterwalder, A., Pigneur, Y.: An e-Business Model Ontology for Modeling e-Business. In: 15th Electronic Commerce Conference e-reality: Constructing thee-Economy, Bled, Slovenia (2002)

8. Bialecki, A.: REA ontology (2001) http://www.getopt.org/ecimf/contrib/onto/REA/.9. Pigneur, Y.: E-business Modell Ontology for improving Business/IT Alignment.

In: CAISE. Volume 2 of Proceedings of the CAISE’05 Workshops Vol. 02., Porto,Portugal, Feup (2005)

10. Osterwalder, A., Parent, C., Pigneur, Y.: Setting up an ontology of business models.In: EMOI-Interop Workshop 2004, Riga (Latvia) (2004)

11. Antoniou, G., Harmelen, F.v.: Web Ontology Language: OWL. Springer (2004)12. Porter, M.E.: Competitive Advantage: Creating and Sustaining Superior Perfor-

mance. Free Press (1985)13. Geerts, G.L., McCarthy, W.E.: An Ontological Analysis of the Primitives of the

Extended REA Enterprise Information Achitecture (2000) Working Paper.14. Lampe, J.C.: Discussion of an ontological analysis of the economic primitives of

the extended-REA enterprise information achitecture. International Journal ofAccounting Information Systems 3 (8) (2002) 17–34

15. Geerts, G., McCarthy, W.E.: The Ontological Foundation of REA Enterprise In-formation Systems (2005) Working Paper.

16. Haugen, R., McCarthy, W.E.: REA: A Semantic Model for Internet Supply ChainCollaboration. In: Proceedings of the Business Objects and Component Designand Implementation Workshop VI: Enterprise Apllication Integration. (2000)

17. Fernndez-Lpez, M., Gmez-Prez, A., Juristo, N.: METHONTOLOGY: From onto-logical art towards ontological engineering. In: Working Notes of the AAAI SpringSymposium on Ontological Engineering, Stanford, AAAI Press (1997)

18. McCarthy, W.E.: The REA Modelling Approach to Teaching Accounting Infor-mation Systems. Issues in Accounting Education 18 (2003) 427–441

19. McCarthy, W.E.: Semantic Modeling in Accounting Education, Practice, and Re-search: Some Progress and Impediments. In Akoka, J., Kangassalo, H., Thalheim,B., eds.: Conceptual Modeling: Current Issues and Future Directions. Springer(1999) 144 –153

20. UN/CEFACT: UN/CEFACT Modeling Methodology (UMM) User Guide. Tech-nical Report CEFACT/TMG/N093, UN/CEFACT (2003)

21. : E-Commerce Integration Meta-Framework. Final draft. Technical report, ECIMFProject Group (2003)

22. O’Leary, D.E.: On the relationshsip between REA and SAP. International Journalof Accounting Information Systems 5 (2004) 65–81

23. McCarthy, W.E.: The REA Accounting Model: A Generalized Framework forAccounting Systems in A Shared Data Environment. The Accounting Review(1982) 554–78

24. Geerts, G., McCarthy, W.E.: Policy-Level Specification in REA Enterprise Infor-mation Systems (2005) Working Paper.

25. Hammer, M., Champy, J.: Reengineering the Corporation: A Manifesto for Busi-ness Revolution. Harper Business (1993)

26. Ijiri, Y.: The Foundations of Accounting Measurement. Prentice-Hall (1967)27. Geerts, G., McCarthy, W.E.: Modeling Business Enterprises as Value-Added

Process Hierarchies with Resource-Event-Agent Object Templates. In: BusinessObject Design and Implementation. Springer-Verslag (1997) 94–113

28. Ijiri, Y.: Theory af Accounting Measurement. American Accounting Association(1975)

29. Fowler, M.: Analysis Patterns. Reusable Object Models. Addison Wesley (1997)30. Geerts, G.L.: An XML Architecture for Operational Enterprise Ontologies. Journal

of Emerging Technologies in Accounting 1 (2004) 73–9031. Borch, S.E., Jespersen, J.W., Linvald, J., Osterbye, K.: A Model Driven Achitec-

ture for REA based systems. In: Proceedings of the Workshop on Model DrivenAchitecture: Foundations and Applications, Enshede, The Netherlands, Universityof Twente (2003)

32. Spaccapietra, S., Parent, C., Vangenot, C., Cullot, N.: On Using Conceptual Mod-eling for Ontologies. In: Proceedings of the Web Information Systems Workshops(WISE 2004 workshops). Volume 3307 of Lecture Notes in Computer SCience.,Springer (2004) 22–23

33. Baclawski, K., Kogut, P.A., Kokar, M.K., Hart, L., Smith, J., Holmes, W.S.,Letkowski, J., Aronson, M.L.: Extending UML to Support Ontology Engineer-ing for the Semantic Web. In: Proceedings of the Fourth International Conferenceon the Unified Modeling Language (UML 2001). Volume 2185 of Lecture Notes inComputer Science., Springer (2001)

34. Guizzardi, G., Herre, H., Wagner, G.: Towards Ontological Foundations for UMLConceptual Models. In: 1st Int. Conference on Ontologies, Databases and Applica-tions of Semantics (ODBASE 2002). Lecture Notes in Computer Science, Springer(2002)