Since large monolithic ontologies are di cult to handle and reuse, ontology modularization has attracted increasing attention. Several approaches and tools have been developed to support ontology modularization. Despite these e orts, a lack of knowledge about characteristics of modularly organized ontologies prevents further development. This work aims at characterizing modular ontologies. Therefore, we analyze existing modular ontologies by applying selected metrics from software engineering in order to identify recurring structures, i.e. patterns in modularly organized ontologies. The contribution is a set of four patterns which characterize modularly organized ontologies.
Di culties in reusing and maintaining large monolithic ontologies have resulted
in an increasing interest in modularizing ontologies. In the past, several
approaches and tools (e.g., SWOOP1, NeOn Toolkit2) have been proposed to
support the modularization of ontologies. Each of these approaches and tools
respectively incorporates its own de nition and notion of modular ontologies and
criteria underpinning ontology modularization [
The goal of this work is to characterize modularly organized ontologies to contribute to a better understanding of ontology modularization. For this purpose, we (1) extract a number of existing ontologies from the web, (2) select and adopt metrics from software engineering in order to both (3) identify recurring structures (patterns) in modularly organized ontologies and (4) characterize the identi ed patterns. The contribution is a set of four patterns, which characterize modularly organized ontologies.
The rest of this paper is organized as follows: Section 2 provides an introduction to ontology modularization and reviews related work. Section 3 reports on the research design whereas section 4 presents and discusses the results. Section 5 draws a conclusion and points to future avenues of research. 2 2.1
The main idea of modular ontologies originates from the general notion of
modular software in the area of software engineering. Correspondingly, ontology
modularization can be interpreted as decomposing potentially large and monolithic
ontologies into (a set of) smaller and interlinked components (modules). Therefore,
an ontology module can be considered as a loosely coupled and self-contained
component of an ontology maintaining relationships to other ontology modules.
Thereby, ontology modules are themselves ontologies [
In general, ontology modularization aims at providing users of ontologies with
the knowledge they require, reducing the scope as much as possible to what is
strictly necessary. In particular, ontology modules (1) facilitate knowledge reuse
across various applications, (2) are easier to build, maintain, and replace, (3)
enable distributed engineering of ontology modules over di erent locations and
di erent areas of expertise, and (4) enable e ective management and browsing
of modules [
In recent years, the problem of ontology modularization has attracted more and
more attention and, thus, several di erent approaches for modularizing
ontologies appeared. These approaches can be classi ed in two main categories.
The rst main category comprises approaches that focus on the composition of
existing ontologies by means of integrating and mapping ontologies. On the one
hand, approaches addressing integration of existing ontologies are owl:import,
partial semantic import, e.g., [
The second main category comprises approaches for modularizing ontologies in
terms of ontology partitioning and ontology module extraction. On the one hand,
ontology partitioning aims at splitting up an existing ontology into a set of
ontology modules. Approaches for partitioning ontologies are proposed by [
Criteria for modularizing ontologies generally aim at characterizing modular
ontologies. To the best of our knowledge, only [
Based on best practices in Ontology Engineering, ontology design patterns (ODPs)
simplify ontology design by providing a "modelling solution to solve recurrent
ontology design problems" [
In order to characterize reoccurring structures in modularly organized ontologies,
the following approach establishes a methodological basis to guide the research
program of this work. This approach comprises six subsequent steps:
1. Search step: the goal of the rst step is to gather modularly organized
ontologies. We use the Semantic Web gateway Watson4 to search for available
modular ontologies from the WWW. The search query focused on
importrelationships between ontologies covering the same domain. The result is a
set of 77 modularly organized ontologies.
2. Cleaning up step: the second step aims at cleaning up the initial search
results in order to establish a thorough basis for further experiments. This
is necessary because the set of 77 modular ontologies is a icted with
redundancies and incompleteness. This results in a set of 38 modular organized
ontologies constituting a thorough basis for characterizing ontology
modularization.
3. Selection of metrics step: the third step selects a set of appropriate
metrics to characterize modularly organized ontologies. The modular ontologies
could be described by various indicators such as the distribution of classes,
the network of links between modules, the number of internal links in
modules, etc. In general, the literature provides a plethora of various metrics,
which could be applied for characterising modular ontologies. As a starting
point, this work focuses on metrics originating in the area of software
engineering, due to its maturity. In particular, this work adopts the following
metrics from software engineering, which are easier to compute, in order to
characterize modular ontologies [
HCC = 2 (NdHC+NidHC)
NC2 NC where: N dHC: Number of direct Hierarchical relationships between Classes, N idHC: Number of indirect Hierarchical relationships between Classes, and N C: Number of Classes. * Role Cohesion (RC): the number of direct and indirect hierarchical role links.
2 (NdR+NidR)
RC = NRoles2 NRoles where: N dR: Number of direct roles between Classes, N idR: Number of indirect roles between Classes, and N Roles: Number of Roles.
* Object Property Cohesion (OPC): the number of classes which have been associated through the particular object property (domain and range).
2 PNRoles NdC(ri) NrC(ri)
OP C = iN=R1oles (Nc2 NC) where: N dC(ri): Number of ontology Classes in the domain of the role ri, N rC(ri): Number of ontology Classes in the range of the role ri, N C: Number of Classes, and N Roles: Number of Roles.
The cohesion measure is computed as follows:
Cohesion = HCC+ + R+C+ OP C where: , and specify the impact of each type of hierarchical class, role or object property cohesion. In our case, we choose = = = 1. (iii) coupling of the module: it takes an estimation of the inter-dependency of di erent modules and is speci ed as follows: * Hierarchical class dependency (HCD): the number of all direct and indirect hierarchical class relationships to foreign ontologies.
HCD = 12 ( NNeddHHCC + NNeiiddHHCC ) where: N edHC: Number of direct Hierarchical class dependencies between local classes and external classes, and N eidHC: Number of indirect Hierarchical class dependencies between local classes and external classes. * Hierarchical role dependency (HRD): the number of all direct and indirect hierarchical role relationships to foreign ontologies.
HRD = 21 ( NNddHHRR + NNeiiddHHRR ) where N dHR: Number of direct roles dependencies between local classes and external classes, and N eidHR: Number of indirect roles dependencies between local classes and external classes. * Object property dependency (OPD): the number of roles that associate external classes to local ones.
OP D = NeRoles
NRoles where: N eRoles: Number of all roles that have an external class in their domain or range, N Roles: Number of all existing roles in the ontology. * Axiom dependency (AD) : a role or a class is associated to an external ontological element through an inclusion axiom.
PNAxioms externalAssociationNumber(axmi)
AD = i=1 PiN=A1xioms LS(axmi RS(axmi) where: LS(axm): the size of the left sides of the axiom axm, RS(axm): the size of the right sides of the axiom axm, LSE(axm): the number of external elements in the left sides of the axiom axm, RSE(axm): the number of external elements in the right sides of the axiom axm, and externalAssociationN umber(axm): the number of all external ontological elements that have been associated through the axiom axm to internal elements. externalAssociationN umber(axm) = LSE(axmi) RS(axmi) + LS(axmi) RSE(axmi) - LSE(axmi) RSE(axmi).
The coupling measure is computed as follows:
Coupling =
HCD+
HRD+ OP C+ AD + + + where, in our case, = = = = 1 4. Metrics implementation step: the fourth step implements the selected metrics. The computation was performed by the OWL API5 and the reasoner HermiT6. This step sets up the (technical) evaluation framework. 5. Analysis step: the fth step is the analysis of the basic population of modularly organized ontologies. 6. Result step: the sixth step involves synthesis and discussion of the results from the analysis in order to characterize modular ontologies. 4
A set of four patterns, which characterize M odular O ntologies MO, are proposed using previous metrics (size, cohesion and coupling). This section presents and discusses the results and the characteristics of each kind of pattern. 4.1
Pattern 1 contains one module which imports n other modules. For instance (Figure 1), the module WildNET.owl imports several modules such as Animal.owl, AnimalSighting.owl, BirdObservers.owl, Birds.owl, etc. The pattern that we propose conforms to an aggregation. This pattern establishes a relationship between a single module and a set of modules in the same ontology. This link is unidirectional. Applying the size metric (Table 1), the rst part of the ontology (one module) is very small (the module WildNET.owl contains 0 concepts) 5 http://owlapi.sourceforge.net/ 6 http://hermit-reasoner.com/ and the second part (N modules) is not structured and is respectively bigger in size. Applying the cohesion and coupling metrics (see Table 1), Pattern 1 has a high cohesion compared to the coupling metric. We consider the pattern cohesion metric to be an indicator of the degree to which the elements in the module belong together. The idea of this pattern is that the concepts grouped in an ontology should be conceptually related for a particular domain in order to achieve common goals.
Metrics
Pattern 2 contains n modules, which respectively import one module. For instance (Figure 2), there are three independent modules importing one module, which containes general knowledge (biopax-level1.owl ). The pattern that we propose corresponds to inheritance. This pattern establishes a correspondence between a set of modules and a single module in the same ontology. This correspondence is unidirectional. Applying the three metrics (Table 2), the rst part of pattern 2 (n modules), biopax-example-ecocyc-glycolysis.owl, biopax-exampleXwnt-b-catenin.owl and Xwnt-b-catenin xref have a high coupling metric with regard to the second part of the pattern (one module) biopax-level1.owl. This means that pattern 2 is characterized by the interconnections between modules. The degree of coupling depends on how complicated the connections are and on the type of connections between modules. As we can see, the second part of pattern 2 has a high cohesion because it encloses all other modules, which are strongly related.
Pattern 3 contains n modules, which import n-1 modules. For instance (Figure 3), we have three dependent modules: dublincore.owl, terms.owl and dcmitype.owl. The correspondence between modules is bidirectional. The distinguishing characteristic of Pattern 3 is that the n modules each import each other. Applying size, cohesion and coupling metrics (Table 3), the module dublincore.owl has a small size (0 concepts) with regard to other modules dcmitype.owl and terms.owl. All modules have the same degree of relatedness of concepts (cohesion) 20%. The coupling metric of the module dublincore.owl is null. In this case, pattern 3 is transformed to pattern 1 and has the same characteristics. Pattern 4 combines all previous patterns (Patterns 1, 2 and 3). For instance (Figure 4), we nd partterns 1 (5 * Pattern 1) and 2 (3 * Pattern 2). The proposed pattern is pattern mix. The correspondence can be undirectional and bidirectional. The major characteristic of this type of pattern is the highest coupling metric with regard to the cohesion one. Two modular ontologies isometadata and iso-19115, have the same size, cohesion and coupling but they do not have a relationship like import. 4.5
Having introduced and de ned four types of patterns in order to characterize modularly organized ontologies, we consider how often these types of patterns M O41 iso-metadata 2214 iso-19108 159 iso-19103 224 iso-19115 2214 0,02 0,08 0,15 0,02 0,15 0,16 0,16 0,15 respectively occur. Figure 5 provides an overview of the occurrence of the di erent types of patterns in a population of 38 modularly organized ontologies. It is interesting to observe that pattern type 1 accounts for about 37%. The reason for this may be the fact that this type of pattern appears to be very intuitive. It could therefore be concluded that it implicitly constitutes the rationale underlying a large part of (semi-)automatic or manual approaches for modularizing ontologies. Similarly, pattern type 4 also accounts for about 37% of the basic population, i.e. 14 modularly organized ontologies. Pattern type 4 combines Pattern 1, Pattern 2, and Pattern 3. On the one hand, it is obvious that not all modularly organized ontologies have a rather straightforward structure, which could be easily characterized. This is especially true when assuming (semi-)automatic or manual modularizing approaches, which do not use clear and precisely dened criteria. And even when these criteria are clearly and precisely de ned, the modularly organized ontologies could also have such a structure depending on the overall purpose of modularization. On the other hand, it is interesting to see that even more complex structures can (almost completely) be characterized by more simple and straightforward structural forms. Moreover, pattern type 2 and pattern type 3 equally account for about 13%, i.e. 5 modularly organized ontologies. This is particularly interesting because pattern type 2 is reasonable. This is due to the fact that it appears obvious that there exists an ontology that is of signi cance for several other ontologies. On the contrary, pattern type 3 is much less reasonable than pattern type 2. It is really hard to understand why ontology modules respectively import each other.
In this context, it can be observed that domain ontologies combine a clear structure and organization. This means that modularization of domain ontologies tend to rely on pattern type 1 or pattern type 2. In contrast, it appears that top-level ontologies (which represent relevant knowledge to a particular domain such as medical domain) have a less straightforward structure and organization particularly when compared to domain ontologies (which represent upper (generic) ontologies, covered the knowledge of many domain types such as Biomedical ontology, Dolce). An example for this is dublincore.owl, terms.owl and dcmitype.owl, which can be characterized by pattern type 3 (Figure 3). 5
This work aims at characterizing modularly organized ontologies to contribute to a better understanding of ontology modularization. We introduced the notion of modular ontologies, reported on approaches for ontology modularization, and reviewed existing e orts to characterize modular ontologies. To characterize modular ontologies, we followed an approach comprising six consecutive steps. This approach mainly includes the extraction and selection of modular ontologies, the selection of a set of metrics from software engineering to analyse modular ontologies, and the evaluation of the analysis results. The evaluation results in a set of four patterns, which allow for characterizing the modular organization of ontologies. These patterns show amongst other things that modularly organized domain ontologies have a clear structure whereas top-level ontologies tend to have a rather confusing modular organisation.
In the future work, we aim at using rstly further Semantic Web gateways such as Falcons or Swoogle to identify and extract additional ontologies to gain a larger basic population. Second, extending the set of metrics and applying them to the ontologies should provide further insights to modular ontologies. Third, it would be interesting to create a comparison framework to conduct experiments with di erent modularization approaches, comparing them to each other or to manually modularized ontologies.
The authors would like to thank the organizers of Summer School on ontology engineering and the Semantic Web 2001 (SSSW'2011).