There are ontology domain concepts that are difficult to represent due to the complexities in their definition and the presence of multiple alternative criteria to classify their abstractions. To assist ontologists in overcoming these challenges, an analysis of available design patterns in ontology and object-oriented modeling has been carried out. As a result, the View Inheritance Ontology Design Pattern (ODP) is introduced. The pattern extends the Normalization ODP (a.k.a. Untangling or Modularization) and revelas the notion of Inter- and Intra-criterion Multiple Inheritance. Our contribution is illustrated with a concrete example of a use case scenario that benefits from the outcome of this study.
Ontologies have emerged as one of the key components needed for the realization
of the Semantic Web vision. Ontologies bring with them a broad range of
development activities that can be grouped into what is called ontology engineering.
Ontology engineering practices present many similarities to those in the software
engineering field and there have been different adaptations of software
engineering principles to the ontology engineering domain [
In this study, we introduce the View Inheritance ODP. The View Inheritance
pattern intends to represent ontology domain concepts that presents multiple
alternative criteria to classify their abstractions. The motivation that led us
to the development of the View Inheritance pattern originates in the ReSIST
(Resilience for Survivability in Information Society Technologies) project [
Among all the ReSIST concepts, one that particularly stands out from a
representational point of view is the concept of “Fault”. The concept of “Fault”
referred hereto is extensively detailed in [
The representation of multiple alternative criteria (views) to classify the abstractions of a certain domain concept motivated the development of the View Inheritance ODP, which is explained throughout the paper as follows: Section 2 presents a brief overview of the main work related to the modeling of ODPs. Section 3 introduces the View Inheritance ODP in detail and finally, Section 4 covers the conclusions gathered from this endeavor and open lines for further investigation. 2
An initial set of ODPs is introduced in [
Experiences in the development of large ontologies in the Biology domain
led to the development of a separate repository of ODPs4 [
From all the patterns surveyed, only the Normalization ODP [
To achieve this however, it relies on modelling constructs available only at the OWL-DL expressivity level of the OWL language (such as owl:disjointWith and to some extent owl:intersectionOf ). This also implies the need of an OWL-DL capable reasoner in order to fully benefit from the use of this pattern. Unfortunately, in the context of ReSIST support for OWL-DL reasoning is beyond the scope of the project.
Another aspect where the Normalization ODP and the representation of
“Fault” in ReSIST diverge is connected to the normalization criteria of the
pattern. These criteria requires the primitive skeleton of the domain ontology
to consist only of disjoint homogeneous trees [
Praising the virtues of the Normalization pattern, we attempted to find
complementary material to characterize the modelling scenario that the many faces
of “Fault” presents. In that sense and again in the domain of O-O software, the
rationale of View Inheritance given in [
In summary, the related work referred hereto, provided an essential framework that served as the basis for the proposed View Inheritance ODP to assist with the development of the ontology component of ReSIST. 3
It might be too early to consider View Inheritance a full right member of the ODP family given that certain aspects of it are still being refined and a more extensive collection of archetypal use cases is still needed. The intent of the pattern is to provide a characterization to the ontological modelling problem of representing a certain domain concept whose abstractions can be classified according to multiple alternative criteria. It represents all of these relevant classification criteria so that multiple possible combinations of the concepts that refine them are allowed.
The applicability requirements below stems from the use of View Inheritance
in the O-O design [
Structure (Diagram). Figure 2 provides a generic graphical representation of the View Inheritance pattern while Figure 3 shows a subset of the classes involved in the overall representation of “Fault” and how it aligns to this generic structure. Elements and Relationships. The classes participating in the pattern together with their responsibility are listed below. The generic names for classes corresponds to classes located in Figure 2 and the names of classes from the representation of the “Fault” example are located in Figure 3.
– TargetDomainConcept (Fault) • This class represents the ontology domain concept being defined for which multiple alternative abstraction criteria exist. – Criterion i (BasicViewPointFault, MajorGroupFault, NamedClassFault, NamedCombinedFault) • These classes represent each one of the alternative abstraction criteria of the TargetDomainConcept (Criterion1, Criterion2, Criterion i in Figure 2). The list of classes may not be exhaustive or pairwise disjoint. – Ci Class x5 (All subclasses of BasicViewPointFault, MajorGroupFault, NamedClassFault, NamedCombinedFault) • These classes refine each abstraction criteria class (C1 Class1, ..., C2 Class1, ..., Ci Class i in Figure 2). The list of classes may not be exhaustive or pairwise disjoint. – CiClass x CjClass y6, Ci Class xClass y7 (FaultType1, FaultType2, ..., FaultType32) • These classes participate in multiple inheritance relationships combining different refinements from the alternative abstraction criteria classes (C1Class3 C2Class2 and C1 Class1Class2 in Figure 2).
Inter- and Intra-criterion Multiple Inheritance. There is an interesting feature regarding the types of multiple inheritance relations that can take place in the context of a View Inheritance pattern, that to the best of our knowledge has not been made explicit so far in ontology modeling. These types of multiple inheritance relationships can be characterized as: – Inter-criterion, when the parent classes involved in the multiple inheritance relation are subclasses of different abstraction criteria. The class C1Class3 C2Class2 in Figure 2 is an example of this type of inheritance because one of its parent classes, C1 Class3, is a refining concept of Criterion1 and the other parent class, C2 Class2, is a refining concept of Criterion2. – Intra-criterion, when the parent classes involved in the multiple inheritance relation are subclasses of the same abstraction criterion. The class C1 Class1Class2 is an example of this type of inheritance because all of its parents classes, C1 Class1 and C1 Class2, are refining concepts of the same criterion, Criterion1. – Intra- and inter-criterion, when there are at least two parents involved in the relation that are subclasses of the same abstraction criterion and there is at least one more different parent that is a subclass of a different abstraction criterion. An example of this type of inheritance is trivial to extrapolate from the composition of the previous two.
Nested View Inheritance. It is worth noting that View Inheritance patterns could occur in a nested fashion. That is, a View Inheritance pattern with a concept Ci as root, could enclose another case of a View Inheritance pattern with a different concept Cj as root where Ci subsumes Cj.
As an example, consider the View Inheritance scenario with “Fault” as root in Figure 3. Let us focus in the subtree that originates in one of its abstraction criterion, in this case “BasicViewPointFault” and zoom in on it. From the point of view of “BasicViewPointFault” and with this concept as root, its direct subclasses (“ObjectiveFault”, “BoundaryFault” and so on) could be regarded as alternative abstraction criteria of “BasicViewPointFault”. The classes “FaultType1” and “FaultType2” could be regarded as cases of inter-criterion multiple inheritance given that each one of their parents is a class subsumed by a different abstraction criterion of “BasicViewPointFault”.
ODP Classification. According to the classification in [
Based on the classification of ODPs in [
There are a number of key points that would be worth summarizing. There can be certain ontology domain concepts difficult to represent due to the existing alternative abstraction criteria that define them. That is the case of the “Fault” concept in the context of the ReSIST project.
A survey of the current ontology building techniques was carried out. The Normalization ODP seemed a viable option, yet the pattern did not fully address the definition of “Fault” and the application requirements of the ReSIST project.
To bridge this gap, the View Inheritance ODP is put forward as an extension to the Normalization ODP, combining the latter with the notion of View Inheritance originated in the O-O software design. View Inheritance revealed two basic types of likely relations that could take place in the structure of the pattern: Inter- or Intra-criterion Multiple Inheritance.
These contributions, while not solving all the modelling challenges of the ontology module for ReSIST, do provide additional awareness to be considered in the development process.
Outstanding issues open for future work include the identification of additional examples of real world use cases of View Inheritance. In that sense, we intend to selectively explore the ontologies most frequently used in the data repositories that are part of the Linked Data project8 for possible occurrences of View Inheritance patterns. The ReSIST project is one of the contributors to the Linked Data set of repositories.