Though ontologies are widely used to solve some speci¯c interoperability problems, there is no speci¯c ontology de¯ning what interoperability actually is, independently from any domain. In this paper, we propose and discuss a ¯rst version of such an ontology, namely the OoI (Ontology of Interoperability), which we formalized using the Ontology Web Language (OWL). On the basis of previous research e®orts having lead to UML formalization of our model of Interoperability, we use this paper for presenting the OWL version and for linking and comparing it with other models dealing with Interoperability: maturity models for interoperability like e.g. the Levels of Information System Interoperability (LISI) model, and the Model Morphisms ontology (MoMo), which deals with interoperability of models. Finally, we illustrate in a brief use case how the OoI could be used with MoMo to provide solutions to interoperability problems between two models.
Interoperability is commonly implicitly seen as an objective to reach when
designing complex systems. Regarding to the IEEE association interoperability is
the ability of two or more systems or components to exchange information and
to use the information that has been exchanged [
A system wide interoperability is only possible if all subsystems are able to
work together. This means that all underlying interoperability problems have to
be solved. According to [
Because a simple de¯nition is not su±cient, we try to develop a formal model
of the interoperability problem. The so-called Ontology of Interoperability (OoI)
aims at providing a formal (and thus processable) de¯nition of interoperability,
but also to provide a way to describe interoperability problems as well as possible
solutions. This may on the one hand help to get a homogeneous description of
various interoperability issues. On the other hand, it may be used to ¯nd similar
problems and hence to detect solutions that might help to solve a concrete
problem. The work presented here has been conducted in the context of the
FP6-IST INTEROP Network of Excellence (NoE) Joint Research Activities [
The rest of this paper is structured as follows. First, we present the current
state of the Ontology of Interoperability (OoI). We then explore links with other
models or e®orts concerning Interoperability modelisation. We brie°y explain
existing links with the interoperability Glossary [
It is our objective to propose a formal and general model for the de¯nition of Interoperability in order to serve as a representation for common understanding. Using a clear problem-solving pragmatic view, the ultimate goal is to de¯ne a framework for the creation of Problem-Solution-Induced Problem knowledge base supporting decision in the domain of interoperability.
Interoperability is a problem pertaining to systems of any sorts. As this concept is often associated to information systems, it is also very often considered as communication issues between or inside systems. However, beyond software engineering and computer science in general, interoperability problems can also occur between `hardware' components. Starting from a systemic point of view, we do not restrict the scope to information system, but rather consider a system as a group of independent but interrelated elements comprising a uni¯ed whole4. Generally speaking, the components of a system do not necessary have to communicate, but might simply have to be composed together for a speci¯c purpose.
From a pure compositional point of view, this can be viewed as a structural interoperability need. When communication or other kinds of action de¯ne the relation between the system's components, this concerns the behavioral aspect of interoperability. In our view, interoperability is not only a matter of communication as it does not necessarily imply a behavioral aspect. According to this, we propose the following de¯nition: De¯nition 1. An interoperability problem appears when two or more heterogeneous resources are put together. Interoperability per se is the paradigm where an interoperability problem occur.
According to this de¯nition, we created the OoI, which is based on research we
have published in [
The OoI is structured according to a series of more general models describing the important concepts that appear in the de¯nition: problem and solution, resource composition, and system. Our ontology establishes relations between these three fundamental models. At a conceptual level, these relations are suf¯cient to provide a de¯nition of what interoperability is. However, at a more operational level, i.e. when the ontology is used to structure or describe real cases or if one wishes to set up an interoperability problem-solution knowledge base, this is not enough. For this reason, we detailed further some of the concepts arising in the de¯nitional part of the model by providing other speci¯c models pertaining to the two classes of solutions: homogenization and bridging, as well as to communication.
In the next part of this section, we shall brie°y present each fundamental models followed by the interoperability and more speci¯c models. The systematic de¯nition of the most important concepts and relations of the OoI is out of the scope of this paper. However, the complete OWL ¯le can be obtained from the authors. 2.1
Because interoperability has been de¯ned as a problem, and because we adopted a clear problem-solving position regarding our de¯nition of ontology, the decisional model is at the heart of OoI. This model clearly separates the problem from the solution, enforcing prior analysis of the problem before suggesting any solution. As modelling problems independently in a reductionist view reduces drastically the complexity of the decision, we did not represent problem composition directly. Rather, relations between problems are only seen indirectly through the introduction of new problems induced by the solutions selected to solve other problems. These new induced problems should then be solved recursively.
Both problems and solutions are related to existence and application conditions, respectively. These are essential, to take into account the context of the decision, i.e., among all possible problems and solutions, the subset of those that are pertinent with respect to the particular situation.
Problems and solutions are often related by a temporal entailment. Indeed, the solution used to solve a particular problem may be applied before the problem e®ectively occurs, or after it occurs. Therefore, solutions that solve problems by anticipation are called a priori solutions, and solutions that correct problems after they occurred are called a posteriori solutions. 2.2
Interoperability problems occur only when resource are put together to form a target system. The resource composition model identi¯es the resources, their objectives and their composition relations. Here, resources are de¯ned as `things' that can be manipulated and put in relation with others.
Relations between resources can be either structural (e.g. between a plug and a socket) or behavioral (e.g. calling a Web Service). They are `physically' realized through an interface which, as a resource itself, is also part of the resource. All sorts of relations are considered, and according to our model, communication is a particular kind of behavioral relation.
The objective associated to the resource is an important concept that can be somehow related to the existence and application conditions of problems and solutions in the decisional model. The objective of a resource states what the resource is useful for. Similarly, technical aspects can also be related to objectives of resources and systems of resources. This enables relating contexts (e.g. technical aspects, existential and application conditions) with resources and systems. 2.3
Composition of resources results in the formation of a system. As for each individual resource, every system subsumes an objective to achieve, which is not simply the composition of the individual objective of the composing resources.
In engineering, resources and systems are the result of a building process. The result of such building process is a system, built from an a priori model. Such model is most of the time established from a description of the reality (or a part of it). This description of reality also constitutes a model of a pre-existing system. From this observation, it appears that system and model relations are dual: on one hand, certain models describe existing systems with the objective of understanding the reality; while on the other hand, certain models de¯ne a new system to build. Analysis and speci¯cation models in software engineering are typically such models where one has ¯rst to understand the business and draw a model of it, and then derive another model specifying the software that will support that business. This indirect relation between the system to understand and the system to build also implies a time entailment where the model used to describe a system always comes before the model de¯ning the new system. The relation with a priori and a posteriori solutions in the decisional model is quite straightforward. Indeed, if the point of reference is the building process of a new system, according to circumstances, one may either solve problems before building the system (in that case, the solution will act on models used to de¯ne the new system), or after the system has been built (in this case, the solution acts on the system itself, most often by inserting a new resource).
If models are used to de¯ne new systems, they can also be de¯ned by other models. The representation of the model is important in our context as this corresponds to their materialization. Indeed, model representations are systems themselves constituted by a composition of symbols. This will be of particular importance when discussing syntax issues in interoperability. 2.4
From the three fundamental models we have presented, we can now de¯ne more precisely the interoperability. As stated in the de¯nition we adopted, interoperability is viewed as a problem, and is thus logically implemented as a subclass of the concept of problem. Such problems are related to the composition of resources, whatever the kind of relations between these resources. As resource composition is strongly connected with the concept of system, interoperability problems occur in and between systems. Since it is a problem, interoperability also bears a condition of existence, which pertains to the domain of resource heterogeneity. Resource heterogeneity arises at the levels of models in the systemic part, or at the level of interfaces in the resource composition part. Models are the origin of heterogeneity when the di®erent resources and systems to built have been made from di®erent models. In the resource composition, the source of heterogeneity is concentrated on the interfaces. Indeed, if interfaces are homogeneous, there is no interoperability problem whatever the internal structure of the inter-related resources. An interoperability problem can obviously appear at one or both levels. Interface compatibility check when putting resources in relation will detect `surface' apparent interoperability problems (for instance, the diameter of the screw is di®erent from the diameter of the nut, or method signature of a library are not compatible with the calling program). Di®erently, if one wishes to identify more `internal' possible incompatibilities (for instance when nut and screw are made of plastic and steel), one has to go back to the models, if they are available.
Solutions pertaining to the interoperability problem are of two kinds. A priori interoperability solutions are of the homogenization type, while a posteriori solutions are of the bridging type. As they are important concepts for interoperability, we derived two dedicated models, which we describe here.
An homogenization solution requires two basic applicability conditions to be e®ective: ¯rst, the modi¯cation of the system must be possible, and second, one must have a su±cient knowledge about the systems and resources to homogenize. Such knowledge is in fact contained in the models that have been used to build the systems. If homogenization is generally the preferred solution to ensure a good validation of the resulting system, this solution is often hardly feasible due to lack of control on the legacy system preventing one from modifying it and/or lack of models. Homogenization is an a priori solution that acts on models. Fundamentally, its objective is to transform the models de¯ning the systems and resources that are put in relation so that the heterogeneity is removed and a new homogeneous system is re-built.Homogenization requires transformations, which can be either syntax transformations (for instance transforming RDF triples from their XML syntax to the N3 notation) or more intricate semantic transformations (transforming a UML class diagram in a Relational diagram involves the consideration of semantic aspects). Transformation are always made using a uni¯ed model, which can be of several kinds. Indeed, one can use a uni¯ed language to achieve homogenization (for instance, re-write all software components in a package using the same programming language, or deciding that everybody will speak English in a meeting to solve the communication behavioral relation problem), a uni¯ed meta-model (or ontology) to reduce semantic heterogeneity, or a uni¯ed interface (as e.g. in the universal plugs and sockets).
Homogenization introduces a series of problems. One of the most prominent one is certainly the validation or the uni¯ed model and the veri¯cation of transformations. Obviously, modifying an existing resource or system is a new source of error which may generate problems that have been solved in the original systems. In addition, performance issues due to uniqueness of resource may also arise.
When homogenization is not possible (no modi¯cation and/or no information about the legacy system is available) or when it creates more problems than it can solve, bridging is the alternative. Bridging consists in adding a new resource in the system capable of eliminating the heterogeneity. This resource is called an adapter and uses a translation protocol. These ones can act at di®erent systemic levels and on di®erent relation types. Indeed, a plug adapter between e.g. DIN and US standards acts on a structural relation at the level of the system's resources, while MOM (Message-Oriented Middleware) acts at the level of the model representation carried out by the message.
Bridging solutions induce a series of problems related to performance and integrity. Performance problems are mainly due to the translation process that take place in the bridging solution. This translation is resource consuming and requires a careful veri¯cation of requirements in terms of performance and response time for the whole system. Moreover, the new added component may introduce alterations of the robustness, the security or the safety of the system. 3
To our knowledge, our attempt to de¯ne a formal model of what
Interoperability is, is the ¯rst one. However some models dealing with Interoperability
already exist. In the INTEROP NoE, another initiative to de¯ne more precisely
interoperability conducted to the Glossary [
Work on ontologies of interoperability is still very scarce. However, one e®ort in
this area has been undertaken within the INTEROP NoE, where a task group
has developed a glossary for interoperability concepts [
However, it can still be useful to compare the Glossary e®orts with the OoI. A preliminary comparison that has been undertaken shows many interrelationships. One ¯nding is that the OoI contains more specialized concepts than those of the Glossary which suggests further re¯nements of the Glossary. The Glossary on the other hand can enrich the OoI by supplying established terms in the interoperability domain. 3.2
There exist a few models of Interoperability. Among them, a widely recognized
one seems to be the LISI (Level of Information Systems Interoperability) model
[
From this report and previous models, it is clear that interoperability is
not speci¯c to the technical layer. Human-related layers play also a role and a
part of them like e.g. business needs are even at the origin of interoperability
problem [
While we try to achieve a quasi-formal description of what Interoperability
is, so that it can be used to ¯nd and solve interoperability problems in systems,
the maturity models we cited provide descriptions of how systems should be
structured to get a given level of interoperability between their components.
The goals are di®erent, and are in fact complementary. From the point of view
of our ontology, maturity models could be associated to speci¯c sets of solutions
to identi¯ed interoperability problems. Once all (or a su±cient number of) the
solutions of such a set are used in a system, this one would then be stamped as
being interoperability level-X compliant according to a chosen maturity model.
With LISI, this could be achieved using the interoperability pro¯les de¯ned
with the PAID method [
As the description of each level de¯nes solutions pertaining to interoperability problems, it should be formalized using the OoI. We illustrate this with the LISI model, on its level 0. LISI level 0 describes interoperability between isolated systems. Each system can be considered as being a resource, part of a bigger system. These resources need to transmit data. At design time, interoperability problems are solved a priori, using adequate interfaces and bridging solutions : e.g. a disk is a bridge, linked to the physical disk controller of computer systems. But this is only the visible part of the iceberg. Pushing further, as soon as we use the disk as solution, we enable data transmission between systems, but other induced interoperability problems need also to be solved: ¯le system compatibility, vocabulary used in the data, the semantics, etc. Hence it can easily be seen that we can follow the reasoning described in the OoI to express the simplest level of the LISI maturity model. Other levels can be expressed as well, however the more complex the system, the more layers of problems-solutions and induced problems there will be. This complexity, which is inherent to interoperability, induces logically the need to have a more complete as possible formalization if we want to automate the ¯nding and resolution of interoperability problems. Modeling is used in almost all areas of (business) information systems today. Models help to keep an overview about complex scenarios and they abstract from the reality. Today, there are plenty of formats and approaches for performing modelling within all major areas. For example, in the database design, Entity-Relationship models (ER) are very popular. When developing software architectures, UML has become a major standard for modelling.
One can distinguish between di®erent types of models as presented in [
In order to achieve its goal, MoMo starts with the creation of a so called Model Morphisms (MoMo) ontology that represents models and their relationships. This ontology aims at helping a user to select a modelling language according to his speci¯c needs. This makes it necessary to analyse the relationships between di®erent modelling languages and hence, it is necessary to analyse their interoperability issues. The link between MoMo and the OoI, proposed in the next section consists in the application of MoMo as one speci¯c use case that can be described by the ontology of interoperability. We created instances in our ontology model that expresses the problem of selecting speci¯c techniques of the model morphism domain. Afterward we added the MoMo framework as a possible solution to this task. 4
This section illustrates how the OoI could be used for representing the
interoperability problems covered by the Model Morphisms ontology. The MoMo
ontology itself tries to solve a part of the interoperability problem:
interoperability between models. Hence, the OoI can be used to model an interoperability
problem between two modelling standards and the MoMo can be linked with it
as one possible solution to this problem. In order to realize this, we started from
two modelling standards: EPC [
The Event-driven Process Chains (EPC) model has been developed within
the ARIS framework [
This example shows one speci¯c scenario for two technologies that could be used to solve a speci¯c problem. Both concepts (BPEL and EPC) are used in the same domain but they di®er in their functionality and in their capabilities. Transforming a process from one standard to the other is certainly not an easy task and needs to consider various interoperability problems. This is where the OoI comes in. It can be used to describe the interoperability problem in this area and it can also model possible solutions for the interoperability problems. For example, if we think of the problem of selecting one of those standards (BPEL or EPC) for a speci¯c tasks then we could for example interpret the MoMo framework, described in the las section, as a possible solution. In order to proof if the OoI can be used in such a scenario, we have added both EPC and BPEL standards as separate instances of the momo:modelling language concept. Furthermore, we created an instance of the concept ooi:solution, which represented the MoMo framework. Afterward, we ¯nished the case study by adding connections between EPC and MoMo as well as between BPEL and MoMo. The outcome is a description of the interoperability problem between EPC and BPEL in the OoI. Moreover, not only the problem was modeled but also one possible solution, which is the MoMo framework. 5
We have presented here our attempt to provide a formal model for
interoperability in the form of an OWL ontology; namely the Ontology of Interoperability
(OoI). The approach and concepts used have already be explained in previous
papers [
In a next step we will use our ontology to model some real-world interoperability problems. This will be performed by describing typical scenarios and giving a representation in the ontology of interoperability. We also plan to investigate further maturity models and trying to formally link one of them to our ontology. Also as we found mainly US initiatives, we would like to investigate European equivalents. As for the moment, the OoI while being a conceptual model, deals mainly with technical aspects, it would also be interesting to model the multiple facets of interoperability that are rather linked to human aspects.