=Paper=
{{Paper
|id=Vol-210/paper-11
|storemode=property
|title=Combining Contexts and Ontologies: A Case Study and a Conceptual Proposal
|pdfUrl=https://ceur-ws.org/Vol-210/paper11.pdf
|volume=Vol-210
|dblpUrl=https://dblp.org/rec/conf/ecai/RicoCCG06
}}
==Combining Contexts and Ontologies: A Case Study and a Conceptual Proposal==
https://ceur-ws.org/Vol-210/paper11.pdf
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