Combining Contexts and Ontologies: A Case Study and a Conceptual Proposal Mariela Rico 1 and Ma. Laura Caliusco 2 and Omar Chiotti 1, 3 and Ma. Rosa Galli 1, 3 Abstract. Recently, approaches that combine contexts and ontolo- ties, but the communication between systems can be achieved only gies taking advantages of their strengths have been developed. Each by constructing explicit mappings [4]. of them solves different problems from different perspectives. The Therefore, taking into account that the strengths of ontologies are objective of this paper is to present problems that are not solved up the weaknesses of contexts and vice versa, a number of approaches to date as well as to introduce a conceptual proposal. To this aim, we were developed which propose to combine both concepts to achieve base our analysis on a collaborative B2B scenario that is relevant for information semantic interoperability. Following, we analyze two of todays competitive and highly dynamic environment. them that are recent and improve others previously defined in the area. 1 INTRODUCTION 2.1 A centralized approach Today, there is an increasing interest on combining context and on- tology to define information semantics. The effort for combining In [3], the ECOIN (Extended COntext INterchange) semantic inter- both approaches could be classified according to the objectives to operability framework has been defined. It proposes to define a single be achieved in works focused on: modelling and knowledge repre- ontology consisting of generic terms without specifying their exact sentation [1], [2]; and achieving interoperable systems that require semantics and it specializes them in local contexts to express spe- data from multiple information sources [3], [4]. In the first case, an cific meanings. ECOIN defines mappings structuring lifting axioms ontology alignment that consists on defining different kinds of rela- [7] as a conversion function network, defining them for each modifi- tions between the involved ontologies, is enough to achieve semantic cation dimension according to a context model. ECOIN results in a interoperability. In the other, however, it is crucial to define an ontol- simpler context model, which works very well in a domain where it ogy mapping that consists on defining equivalence relations [5]. is possible to define a single ontology and to relate it with multiple Particularly, our research is focused on achieving semantic inter- contexts. operability between heterogeneous information systems to support a collaborative business-to-business (B2B) relation between trading 2.2 A decentralized approach partners. In this area, the main approaches are focused on the idea of similar ontologies. However, each enterprise has its own informa- In [4], an extension of the OWL language, C-OWL, has been de- tion systems, and the challenge here is how to semantically integrate fined to represent contextual ontologies where a context is a con- these heterogeneous systems. crete domain viewed from the description logic perspective. In this The objective of this paper is to present problems that are not work, ontology is contextualized when its contents are kept local and solved up to now and introduce a conceptual proposal for combining mapped with the contents of other ontologies via explicit mappings context and ontology. To this aim, the paper is organized as follows: using bridge rules. These rules represent the relations: equivalent to, Section 2 presents related works. Section 3 presents a context defi- more general than, less general than, compatible and incompatible. nition. Section 4 presents a case study based on a collaborative B2B C-OWL allows a user to define ontologies alignment where it is in- scenario, and discusses problems that arise when combining contexts appropriate to define a global shared ontology. However, the limited and ontologies. Section 5 presents conclusions and future work. expressiveness of the C-OWL fails to address the contextual differ- ences found in most practical settings, as it will be shown later. 2 RELATED WORKS AND DISCUSSION 3 OUR VIEW OF CONTEXT It is possible to find formal and informal approaches defining an on- tology [5], and a context [6], [7], [8]. Ontologies define a common When we talk about context, intuitively, we think in the set of facts understanding of specific terms, and thus make it possible the seman- in which something exits or occurs. This idea is not reflected by ap- tic interoperability between systems, but they can only be used after proaches described in Section 2. Our intention is to apply the theory reaching consensus about their content. Contexts encode not shared about context [7], [8], for information semantics modelling and com- individual interpretation schemas, that are easy to define and main- bine it with ontology. In our opinion this is a more appropriate way tain since they can be created with a limited consensus among par- to take advantage of both approaches strengths in complex domains. In the theory defined in [7] and [8], axioms and statements p are 1 CIDISI-UTN-FRSF, Argentina, email: mrico@frsf.utn.edu.ar only true in a context c. This fact is expressed by the formula 2 CIDISI-UTN-CONICET, Argentina, email: mcaliusc@frsf.utn.edu.ar 3 INGAR-CONICET, Argentina, email: chiotti,mrgalli@ceride.gov.ar c0 : ist(c; p) The context c is formalized as a first class object. Formulas ist(c,p) describes the EBD information semantics, which was agreed by both are always considered as themselves asserted within a context, c’. Al- partners. The EBDs will be processed by partners’ private processes though this formulas define a infinite regress, to manipulate context that may involve different enterprise sectors. Even two sectors within we have to define a limit. the same enterprise for apparently similar applications have different In information semantics modelling area we could state that a con- views, resulting in similar but still not the same ontology. Then, it text is a set of facts in which a concept interpretation is true. is clear that each enterprise has its own ontologies to describe the semantics of its systems and internal areas. c = {a set of f acts} and p = concept interpretation Figure 1.b shows a part of an ontology (OEBD ) shared by both c and p could be an ontology or an ontology element. trading partners that describes the semantics of EBD interchanged to Defining contexts as a set of facts instead of a label allows us to agree on a replenishment plan. Even if both supplier and client could manipulate them in a flexible way as will be shown next. have multiple ontologies to describe their information semantics, in About contexts relations, there are two proposed ways: lifting ax- this paper and for simplicity purposes, we focus on one ontology for ioms and bridge rules [12]. The main difference between them is that each enterprise, OS and OC respectively, Figure 1.a and 1.c. lifting axioms are stated in an external context, which must be ex- Although the centralized integration proposal (Section 2.1) intro- pressive enough to represent facts of all involved contexts, whereas duces a simpler ontological model, it is difficult and sometimes even bridge rules allow stating relations between contexts without the need impossible to implement this proposal in a collaborative B2B rela- of an external one. In Section 4.3, advantages of having an external tion. That is because each enterprise in a SC has its own interests; context are analyzed. So, a relation R between context will be and its information systems and data structures have been designed R to achieve those interests. So, when these enterprises decide to join c0 : (ist(c1 ; p1 ) −→ ist(c2 ; p2 )) themselves in a collaborative process, they do it with a common in- terest but keeping their individuality and privacy. As regards context, 4 A CASE STUDY the ECOIN definition is not applicable either, since a context is more than just possible instance values in a collaborative B2B scenario. Nowadays, enterprises work together with their trading partners to The decentralized proposal (Section 2.2), seems to be more appro- improve supply chain (SC) management. Then, there is a semantic priate to model this scenario, since it handles different ontologies. heterogeneity that could be solved by using ontologies, but it is not However, the manipulation of contexts lacks of needed expressively enough. Two concepts can be differently related to each other in dif- to represent that within the context C RBR exists subcontexts such as ferent contexts, as different enterprises. In a collaborative relation, it Supplier, C S ; Collaborative Process, C CP ; and Client, C C . This fact is primordial that each enterprise preserves its identity, particularly can be modelled with the theory of context described in Section 3 as: the semantic identity. So, it is necessary to make the context explicit. From a business point of view, to allow a decentralized manage- C RBR : ist(C S , pS ) ment, the PartnertoPartner Collaborative Model has been defined in [10], which proposes a peer-to-peer collaboration between trad- C RBR : ist(C CP , pEBD ) ing partners. In this model, decisions are independently made with C RBR : ist(C C , pC ) the aim of preserving the privacy and autonomy of each enterprise. Let us define an example where a brewery has collaborative relations where pS , pEBD , and pC are truth propositions in their contexts. with two of its clients: a retailer and a warehouse; each relation con- stitutes a different context, C RBR and C RBW respectively. The management of each collaborative relation implies coordinat- 4.2 Contexts within an ontology ing: private processes (PP) that are executed by each enterprise; and Considering the Type term of the OEBD ontology (Figure 1.b), it is collaborative processes (CP) that are jointly executed by trading part- associated to the Packaging and Product terms. Even though Type has ners. CP are defined as abstract ones; and in order to implement it the same semantics, since it describes the class or nature of the con- each trading partner has to define a business interface process (IP). cepts it is associated to, the possible values it may take are different. This IP is responsible for the invocation and execution of those PP In the case of Packaging, Type can be Can or Bottle. But, for Product, required for carrying it out. To allow the CP execution, Electronic Type can be Local or NKH. This presents an ambiguity problem that Business Documents (EBDs) are exchanged between trading part- could be solved by replacing the term Type by PackagingType and ners. EBDs are standardized data structures that replace traditional ProductType. In this way, however, terms are unnecessarily added business documents [11]. to the ontology, and this practice could lead to a size increase [8]. When the IP receives an EBD, it has to translate it information to In our opinion, a better solution is to consider Product and Packag- the PP according to the semantic of corresponding enterprise sector. ing as different contexts inside of which the term Type is interpreted, Then, to send an EBD, the IP populates it with data of corresponding enterprise sector according to the CP semantics. So, to make interop- erable systems, the IP has to solve a number of conflictive situations at semantic level considering that it is necessary to define equiva- lence relations between concepts. Next, some of them are analyzed from the theories defined in the previous sections considering the re- lation between the brewery and a retailer. 4.1 Multiple ontologies and multiple domains Figure 1. (a) Portion of one of the OS ontology. (b) Portion of the OEBD In a collaborative relation, each EBD is described by an ontology ontology. (c) Portion of one of the OC ontology [11] that is not a global or general one, but only an ontology that defining them by a set of formulas like one shown in Table 1. In this and Size ∈ OEBD plus their relations. Analyzing the instances, Pack- table, Product and Packaging refer to OEBD terms, and they are not agingType(Can354cm3) has to be translated into OEBD as: simple labels, which give name to the contexts. OEBD : ist(P ackaging, (T ype(Can)) ∧ ist(P ackaging, Size(354cm3)) ∧ Table 1. Definitions of ProductCxt and PackagingCxt contexts ist(P ackaging, size of (354cm3, Can)) ∧ ProductCxt context PackagingCxt context ist(P ackaging, part of (T ype(Can), P ackaging)) ist(Product, part of(Product, ist(Packaging, part of(Packaging, That means that a certain concept is represented by a term in a Type)) Type)) particular ontology, but is represented as a set of terms, a set of rela- ist(Product, Type(Local)) ist(Packaging, Type(Can)) ist(Product, Type(NKH)). . . ist(Packaging, Type(Bottle)). . . tions and a context in another ontology. This example shows that in order to define mappings between different contexts it is necessary to define conversion rules that are more complex than mapping rules Here, different contexts are created within an ontology with the defined by [4] and the conversion function defined by [3]. aim of solving name ambiguities [8]. This problem has no been tack- led in the literature related to information system interoperability. 5 CONCLUSIONS AND FUTURE WORK The main contribution of this paper is a conceptual proposal that 4.3 Relating contexts combines contexts and ontologies in order to manipulate semantic differences in a complex domain, such as a collaborative B2B sce- Figure 1.c shows a client ontology portion, OC . If the term Trade- nario. This proposal is based on a previously defined context theory, mark is considered, it is an attribute of Product in OC . This means, however, we have explored the possibility to combine it with ontol- it is an attribute of all products and not just of beer. By contrast, ogy concepts. Our approach proposes to define contexts as a set of Trademark ∈ OEBD (Figure 1.b) has a part of relation with Prod- facts that allow us to manipulate it in a more flexible way. uct. Furthermore, Trademark ∈ OEBD has an association with Type, In a complex domain, having an external context may be an ad- which is valid in the context ProductCxt but not on the context Pack- vantage. So, an interesting option to be analyzed is the definition of agingCxt. This relation does not exist in OC because this informa- lifting axioms to define conversion rules between contexts. This anal- tion is irrelevant for the client. In spite of these differences, however, ysis will be the focus of our future work, however, in this paper we we can say that Trademark ∈ OEBD is equivalent to Trademark ∈ have made progress in this sense. An important feature of these con- OC since their instances are equivalent to the collaborative context. version rules is they have to allow us to relate a term in an ontology These terms could be related by using equivalence mapping rules [4]: with a set of terms, a set of relations and a context in another. ≡ The present proposal is incomplete and tentative since this is just OEBD : T rademark −→ OC : T rademark ∧ the first step and further research remains to be done. ≡ OC : T rademark −→ OEBD : T rademark REFERENCES Considering this example, mapping rules defined in [4] are useful [1] A. Segev, and A. Gal, Putting Things in Context: a Topological Ap- in cases where simple equivalence relations are enough to express proach to Mapping Contexts and Ontologies, 9–16, Contexts and On- similarities between contexts. tologies: Theory, Practice and Applications, AAAI Press, 2005. However, if previous rules are analyzed from the client context [2] P. De Leenheer, and A. de Moor, Context-driven Disambiguation in C C point of view, these relations are not truth. The term Trademark Ontology Elicitation, 17–24, Contexts and Ontologies: Theory, Practice of OC is more general than the term Trademark of OEBD , since it and Applications, AAAI Press, 2005. [3] A. Firat, S. Madnick, and F. Manola, Multi-dimensional Ontology Views represents the trademark of all products and not only beers. That is: via Contexts in the ECOIN Semantic Interoperability Framework, 1– 8, Contexts and Ontologies: Theory, Practice and Applications, AAAI ⊆ OEBD : T rademark −→ OC : T rademark Press, 2005. [4] P. Bouquet, F. Giunchiglia, F. van Harmelen, L. Serafini, and H. Stuck- enschmidt, ’Contextualizing Ontologies’, Web Semantics: Science, Ser- Previous rules, defined in this way, could carry incompatibility vices and Agents on the World Wide Web, 1: 4, 321–419, (2004). problems. A possible solution should be to contextualize them: [5] A. Gómez-Pérez, M. Fernández-López, and O. Corcho, Ontological Engineering, Springer Verlag, London, 2nd edn., 2004. ≡ ist(C CP , (OEBD : T rademark −→ OC : T rademark)) [6] P. Brzillon, ’Context in problem solving: A survey’, The Knowledge Engineering Review, 14: 1, 47–80, (1999). ⊆ [7] R. Guha, Contexts: A Formalization and Some Applications. PhD The- ist(C C , (OEBD : T rademark −→ OC : T rademark)) sis. Computer Science Dep., Standford University, 1995. [8] J. McCarthy, and S. Buvac, Formalizing Context (Expanded Notes), It is necessary to clarify that this is not a formalization, but only Computer Natural Language, 1997. a way to express the idea that the rules linking terms belonging to [9] M. Theodorakis, Contextualization: An Abstraction Mechanism for In- different concepts also should be contextualized. formation Modeling. PhD Thesis. University of Crete, Greece, 2001. [10] P. Villarreal, M. Caliusco, M. Galli, E. Salomone, and O. Chiotti, De- centralized Process Management for Inter-Enterprise Collaboration, 4.4 Different contexts, different representations 69–79, Vision, Special Issue on Supply Chain Mgment, 7, India, 2003. [11] M.L. Caliusco, M. R. Galli, and O. Chiotti, ’Ontology and XML-based By comparing OC and OEBD (Figure 1.b - 1.c), the concept repre- Specifications for Collaborative B2B Relationships’, CLEI Electronic sented by PackageType in OC is equivalent to Size and Type terms Journal, 7: 1, (2004). [12] P. Bouquet, and L. Serafini, On the difference between bridge rules and in OEBD , for Type in the PackagingCxt context, but not in the Pro- lifting axioms, 80–93, Proc. 4th CONTEXT, LNCS 2680, 2003. ductCxt context. So, PackageType ∈ OC is related to Packaging, Type