3.3: Ontology modularisation
A complex system must be broken down into smaller modules
Similar to a piece of software, an ontology may tend to become overly large and complex. This often due to domain creep: the amount of concepts and relations that are considered necessary to faithfully model the domain increases over time. But regardless its cause, complexity can only be addressed by breaking it up into a number of less complex parts that represent the whole by working independently (or as independently as possible) together. Indeed, mereology may play a role in ontology modularisation, but more often it is simply a matter of compartmentisation.
Modularisation decreases the level of complexity and, with it, improve the overall quality and maintainability of the distinct parts. Where the latter two are the general objectives of modularisation, a very specific objective of modularisation is to improve its ability to be reused: Where large and complex perspectives on reality may reflect completeness, at the same time the resulting huge artefact addresses too many aspects of the domain of application to allow for reuse. This is because many aspects will show irrelevant or even patently wrong in the new context of use; although reuse may address the same reality, the domain of application may be different due to a different perspective on reality. Consequently, the smaller the ontological artefact, the higher the chance for its reuse.
Therefore, reuse of ontologies is not so much encouraged as it is a logical consequence from modularisation. By describing, representing and maintaining the state of affairs about a coherent topic of interest from the domain of application, the subject can be reused by applications in order to:
save effort (prevent reinventing the wheel);
interact with other ontologies;
maintain a consistent perspective on the domain of application;
improve the semantic quality by allowing different applications to validate its perspective.
The effect of applying modularisation is threefold: easier comprehension by simplification; simplification by decomposability; realising complexity by composability. The effect of reuse is circular: Increasing the modules available for reuse, increases the amount of reuse, which by token of their success increases the amount of modules available for reuse.
We describe in this Section how to go about ontological modularisation and some of its engineering consequences.
Comprehensiveness demands modularisation
Ontologies can only achieve the above objectives (reuse and overall quality and maintainability) when the ontology describes the domain of application faithfully and comprehensively. Being comprehensive does not necessarily imply being huge; being comprehensive relates to the purpose that the ontology is to fulfil. Hence, comprehensiveness is about including all concepts about the domain of application that are necessary in order to fulfil its purpose, but not more than those: Necessary and sufficient concepts only.
Here's where modularisation comes into play. Modularisation facilitates a "limited comprehensiveness scope", identifying only those concepts from the domain of application that are relevant for achieving a certain purpose, e.g., to derive a particular conclusion, to describe several state of affairs, or to answer the CQ's about a certain topic. Then, whenever those concepts are requested by an application, it needs to address that particular ontology module, only.
At the same time, modularisation supports being faithful to reality. Due to its limited scope, the ontology engineer can obtain a better overview, focus on a single aspect without interference of irrelevant side-issues. This translates directly into ease of comparison between different engineering solutions, and hence, selecting the solution that represents reality most faithfully. But more importantly, modularisation facilitates a single perspective on matters: By identifying a single purpose, a single perspective of use is applied as well. This is of high relevance because a combination of multiple points of view allows for conflicts as to when or under what conditions a state of affairs apply. This reduces faithfulness and, subsequently, its potential reuse.
In this way, modularisation becomes a stepping stone for reusing existing ontologies and for constructing custom sub-ontology to potentially be reused.
In practice: the pizzeria case
In ontology engineering we can distinguish various parts in a domain. Take for example (again) the pizzeria domain where it is necessary to consider the Pizzas sold, the Locationof the restaurant and the customer's home, the vehicle that is used to deliver pizzas, and the bakery where the pizzas are baked. This description immediately shows several potential parts that, together and like pizza parts, compose the original whole. Moreover, it is important to note that although these four parts in the domain may be represented by a single ontological concept for each part, these concepts may nevertheless be the subject of an ontology in their own right. By modelling the pizza, the delivery vehicle, the bakery and the location as separate modules, we have effectively created what are potentially four different ontologies. Since each is part of the whole pizzeria ontology, these are called ontology modules.
Engineering consequences
The principled approach in modularising ontologies is not different from that in software engineering. In order to cluster the concepts into separate modules one needs to estabish the particular combination of high cohesion and low coupling. Analyse your ontology and find those concepts that have high cohesion with each other whilst showing low coupling, i.e., few to none relations, with other concepts. Again, look at the purpose that is being achieved in terms of, e.g., CQ's, or topic of interest, and always make sure that reality is being addressed through one single perspective of use.
Then, the modularisation can make the life of ontology engineers a lot easier. There are several directions we would like to explore to show how advanced modularisation can speed up the engineering process.
Setting up the modularisation, i.e., identifying the potential modules, can be one of the first tasks to achieve, although this requires a good insight in the domain of application already from start. When such insight is not readily available from scratch, an iterative and incremental approach works well where modularisation emerges naturally from the purpose of the particular work cycle. This will definitely bring about ontology refactoring work and changes in modularisation, but this should not be considered a bug but a token of building quality instead;
First of all, each modelling task can be linked to a specific module. This makes it very easy to define the Acceptance Criteria for a single module: when its associated purpose can be achieved, the module can be considered complete. When all CQ's can be answered correctly, the module can be considered faithful to the domain (high cohesion);
Links between modules, i.e., relations, can be considered their interface. This allows modelers to implement separate modules without worrying of invalidating each other's work: as long as the constraints that apply for the interfaces between the modules are respected, their interdependency is under control as well. Note that this requires to check all potential combinations that the interfaces can span together, which resents a strong incentive to minimise the amount of relations between modules (low coupling).
The git commit tree also becomes quite more manageable when the ontology contains different modules. After all, this will usually imply that each module is located in a separate file with a separate namespace. Ontology construction can then consist of specifying the main namespace, importing the distinct modules, and connecting them together (realising complexity by composability).
Separating the ontology in modules as different files also facilitates reuse of your modules by other modelers. After all, other modelers do not have to extract a set of concepts from your ontology specification, but can reuse them by importing a complete namespace which addresses a limited and coherent domain perspective.
Reuse of a complete ontology may happen on the level of a single module. This is what we will elaborate on in Section 3.5: Ontology reuse, where we will also discuss the interplay with Competency Questions.
Example: the Pizzeria ontology
Above, we already implied that the Pizzeria ontology can be decomposed into 4 distinct modules. Now we will elaborate on them by analysing the CQ's for these parts. These CQs immediately show which other concepts the Pizzeria ontology relates to. We again take the same CQs and extract the concepts that are mentioned.
Which pizzas are sold by a pizzeria?
Where is the pizzeria located?
Which company does the pizzeria belong to?
Who is the owner?
How does the pizzeria deliver their pizzas?
How does the pizzeria restaurant look like?
The key takeaway is that each bold concept can be the focus of a separate ontology in its own right. We want to make sure that these
Pizza ontology
Location ontology
Company ontology
Person ontology
Delivery vehicle ontology
Restaurant construction ontology
The resulting 6 modules show high internal coherence and low coupling with each other. Together, they construct the ontology under development, while individually they represent a domain on its own. Schematically, the Pizzeria ontology can now be depicted as follows:
This view shows the advantages of modularisation. Through a divide-and-conquer approach we reduced the complexity of the whole and enabled an iterative-incremental way of working. Each module represents its own particular domain with its own business value and can be resolved as a separate subproject.
In practice: reusing ontologies
The reuse of ontologies is not necessarily a fixed step in the process, but is something to keep in mind continuously while performing an iteration. For example, while actually modelling an iteration or specific concept, there are two questions you can ask:
What (basic) ontologies, that we already reuse, can add something to this new iteration/concept being modelled?
Do we specify any concepts or even a domain that may exist already in other ontologies?
When existing ontologies already cover the domain to be modelled, why not reuse it? Use search engines to find relevant ontologies by using keywords and look into this ontology. Decide whether it is useful to make a connection with this existing ontology, or whether this ontology can be used as an inspiration for your own model.
Last updated
Was this helpful?