Over the years, there is a growing interest in employing theories from philosophical ontology, cognitive science and linguistics to devise theoretical, methodological and computational tools for conceptual modeling, knowledge representation and domain ontology engineering. In this paper, we discuss one particular kind of such tools, namely, ontological anti-patterns. Ontological anti-patterns are error-problem modeling structures that can create a deviation between the possible and the intended interpretations of an ontology. The contributions of the paper are three-fold. Firstly, we propose some empirically elicited ontological anti-patterns related to the modeling of taxonomic structures. Secondly, we advance a series of rectification plans that can be used to eliminate the occurrence of these anti-patterns in domain ontologies. Finally, we present a model-based computational tool that supports the automated detection, analysis, and elimination of these anti-patterns.
In recent years, there has been an increasing interest in the application of ontologies in
conceptual modeling, knowledge representation and domain engineering. This includes
the use of foundational ontologies to improve the theory and practice of these disciplines
[Almeida et al. 2009,
Given the increasing complexity and criticality of domains in which ontologies
are being developed (e.g., finances, life sciences, public safety, convergence networks),
there is an urging need for developing a new generation of complexity management tools
for engineering these artifacts [
An anti-pattern is a recurrent error-prone modeling decision [
In this article, we focus on the study of Ontological Anti-Patterns in a particular
modeling language named OntoUML [Guizzardi 2005]. OntoUML is a language whose
meta-model has been designed to comply with the ontological distinctions and
axiomatization of a theoretically well-grounded foundational ontology named UFO (Unified
Foundational Ontology) [Guizzardi 2005,
This article can be seen as complementary to our earlier work on
antipatterns. In [Sales and
The contributions of this paper are three-fold. Firstly, we contribute to the identification of three new Ontological Anti-Patterns for conceptual modeling, in general, and for OntoUML, in particular. Secondly, after precisely characterizing these anti-patterns, we propose a set of refactoring plans that can be adopted to eliminate the possible unintended consequences induced by the presence of each of these anti-patterns. Finally, we present an extension for the Menthor Editor, an open-source OntoUML model-based editor that: (i) automatically detects anti-patterns in their models; (ii) supports users in exploring whether the presence of an anti-pattern indeed characterizes a modeling error; (iii) automatically executes refactoring plans to rectify the model.
The remainder of this article is organized as follows: in Section 2, we briefly elaborate on the modeling language OntoUML and some of its underlying ontological categories, with a particular focus on the modeling of taxonomic structures; In Section 3, we first briefly present the anti-pattern elicitation method employed here and characterizes the model benchmark used in this research; In Section 4, we present the newly elicited Ontological Anti-Patterns with their unintended consequences, as well as possible solutions for their rectification in terms of model refactoring plans; Section 5 elaborates on the extensions implemented in the OntoUML editor taking into account these anti-patterns; Finally, Section 6 presents some final considerations.
OntoUML is a language whose meta-model has been designed to comply with the
ontological distinctions and axiomatization of a theoretically well-grounded
foundational ontology named UFO (Unified Foundational Ontology) [Guizzardi 2005,
Take a domain in reality restricted to endurants [Guizzardi 2005] (as opposed to events or occurrents). Central to this domain we will have a number of object Kinds, i.e., the genuine fundamental types of objects that exist in this domain. The term “kind” is meant here in a strong technical sense, i.e., by a kind, we mean a type capturing essential properties of the things it classifies. In other words, the objects classified by that kind could not possibly exist without being of that specific kind.
Kinds tessellate the possible space of objects in that domain, i.e., all objects belong necessarily to exactly one kind. However, we can have other static subdivisions (or subtypes) of a kind. These are naturally termed Subkinds. As an example, the kind ‘Person’ can be specialized in the subkinds ‘Man’ and ‘Woman’.
Object kinds and subkinds represent essential properties of objects
Phases but also typically subkinds appear in OntoUML models forming (disjoint and complete, i.e., exhaustive) generalization sets (partitions) following a Dividing Principle. For example, we can have the following phase partitions: the one including ‘Living Person’ and ‘Deceased Person’ (as phases of ‘Person’ and according to a ‘life status’ dividing principle). Since they are exclusively composed of phases, these are all dynamic partitions [Guizzardi 2005]. To use a previously mentioned example, we can also have a (static) subkind partition formed by the subkinds ‘Man’ and ‘Woman’, dividing ‘Person’ according to ‘gender’.
Kinds, Subkinds, Phases, and Roles are categories of object Sortals. In the philosophical literature, a sortal is a type that provides a uniform principle of identity, persistence, and individuation for its instances [Guizzardi 2005]. To put it simply, a sortal is either a kind (e.g., ‘Person’) or a specialization of a kind (e.g., ‘Husband’, ‘Teenager’, ‘Woman’), i.e., it is either a type representing the essence of what things are or a subclassification applied to the entities that “have that same type of essence”.
In contrast with sortals, types that represent properties shared by entities of multiple kinds are termed Non-Sortals. In UFO, we have three other types of non-sortals, namely Categories, Mixins, and RoleMixins. Categories represent necessary properties that are shared by entities of multiple kinds (e.g., the category ‘Physical Object’ represent properties of all kinds of entities that have masses, spatial extensions, etc.). In contrast, mixins represent shared properties that are necessary to some of its instances but accidental to others. For example, suppose we have the mixin ‘Physical Object’ capturing properties (e.g., having a ‘Weight’) that are necessary to ‘Cars’, while being accidental to instances of ‘Person’ (people are only physical objects when they instantiate the phase ‘Living Person’). Finally, RoleMixins are role-like types that can be played by entities of multiple kinds. An example is the role ‘Customer’ (which can be played by both people and organizations). Categories and mixins are, in contrast to rolemixins, considered as Relationally Independent Non-Sortals.
We identified the anti-patterns presented in this paper through an empirical and qualitative
method. First, we started by assembling a repository of domain and core ontologies to
validate. Then, for each ontology, we would select relevant fragments to inspect. For each
fragment, we would search for potential issues using an approach called Visual Model
Simulation [Sales and
We systematically repeated the process we just described for the 54 ontologies
available in the OntoUML model repository2. Out of these 54 models, 11 were
developed as a part of academic research, such as O3 [
The ontologies we analyzed were created for a variety of purposes: 10 were
designed to serve as core ontologies
1The set of intended instances correspond to those that represent intended state of affairs [Guizzardi 2005] according the creators of the models.
2Most of these models are available at http://www.menthor.net/model-repository. html. The missing cases are due to non-disclosure agreements.
Moreover, the ontologies we analyzed were developed by modelers with varying levels of expertise in OntoUML: 22 were developed by beginners, whilst 32 were developed by experienced modelers. Finally, regarding the number of participants involved in the ontology construction, 35 models were developed individually, 15 were the product of a collaboration between 2-4 people, and 4 of them involved 7-10 people.
The anti-pattern named Mixin with a Uniform Identity Principle (MixIden) is motivated by the use of a non-sortal metaclass to characterize a type whose instances adhere to a single identity principle. Structurally, it corresponds to a type characterized as a mixin type (from now on, simply M ixin), i.e., a type stereotyped as either mixin , category , or roleMixin ), but whose direct subtypes (T ypei) are all sortals types (i.e., types stereotyped as subkind , role , phase , kind , collective , or quantity ) that share a common identity provider (IdP rovider) as an ancestor.
We say that the subtypes share an identity provider if: (i) there is exactly one identity provider amongst the subtypes and the remainder specialize it; or (ii) there is no identity providers amongst the subtypes, but all of them are directly or indirectly specializations of the same identity provider.
To unveil whether an MixIden occurrence is indeed an error, one should first assess if M ixin represents a type can really possibly classify instances of different kinds, i.e., that obey multiple identity principles. If that is not the case, such type should be represented as a sortal, which can be achieved by: choosing a suitable sortal metaclass for for M ixin (e.g. subkind , role or phase ); make it specialize IdP rovider (see refactoring plan 1 in Table 1).
Figura 1. Adapted fragment from the MGIC Ontology exemplifying MixIden.
Conversely, if M ixin indeed allows different identity principles for its instances, we recommended to make this explicit either by: (i) changing the identity provider of one of the current subtypes (T ypei); or (ii) specializing M ixin with a new sortal that follows a different identity principle. These two alternatives are respectively depicted in refactoring plans 2 and 3 on Table 1.
To exemplify the MixIden anti-pattern, we discuss an example found in the MGIC
ontology [
Tabela 1. Summary of the MixIden anti-pattern.
Name (Acronym) Mixin with a Uniform Identity Principle (MixIden) Pattern Roles Mult. Name 1 M ixin 1..* Sortali 1..* IdP rovider Generic Example
Description A non-sortal class specialized only by sortal types that obey a single identity principle, i.e. specialize a common identity provider class.
Allowed Metaclasses mixin , category , roleMixin subkind , role , phase , kind , collective , quantity kind , collective , quantity Refactoring Plans 1. Mixin to Sortal: change the stereotype of M ixin to either subkind , role or phase and make it specialize IdP rovider. 2. Different Identity: set the identity provider of at least one of the Sortali types to another class (IdP rovider2). 3. Missing sortal: specialize M ixin with another sortal (Sortal3) that follows a different identity principle (from IdP rovider2).
The reason why this fragment exemplifies a MixIden occurrence is the representation of Maintenance Contractor as a roleMixin , even though all its subtypes, namely P.O. Contractor and C. Contractor, inherit their identity principles from the same supertype, the class Organization. As such, this fragment identifies an ontological mistake because only organizations can be contractors, and thus, the contractor role should be represented as a sortal class – following refactoring plan 1.
The Mixin with Uniform Identity (MixRig) anti-pattern warns modelers about a potential misuse of the semi-rigidity meta-property to characterize a class. It does so by highlighting a mixin class (which we refer from now on as the M ixin) whose subtypes (T ypei) are either all rigid ( subkind , kind , collective , quantity , or category ) or all anti-rigid ( role , phase , roleMixin ).
To discover whether a MixRig occurrence is indeed a modeling mistakes, one should start by revisiting the semantics underlying the supposed semi-rigid universal. Is it truly the case that some of the instances of this universal necessarily instantiate it, whilst others do so accidentally? If the answer is no, this universal is not semi-rigid, and thus one should rectify the model by choosing a more suitable metaclass for M ixin (see refactoring plan 1 in Table 2). If all the subtypes are rigid, this can be achieved by changing its stereotype to category , and if they are all anti-rigid, by changing its stereotype to roleMixin .
Contrarily, if M ixin is indeed a semi-rigid type, the problem lies on its subtypes. A possibility is that one of these subtypes has been modeled using a metaclass that embeds an erroneous modal meta-property property (e.g., mistakenly as a subkind something should be in fact a role ). In this case, the solution is simply identifying which subtype carries was mistakenly modeled and fix it accordingly. Another possibility is that M ixin has a subtype that is currently missing in the model, a type which would be characterized with a different rigidity property (e.g., a model fragment in which the present subtypes are subkinds, but in which there is non-represented role type). In this case, the modeler should explicitly include the missing subtype in the model. These two scenarios are described in the refactoring plans 2 and 3 in Table 2.
We illustrate an occurrence of MixRig in Fig. 2 with another taxonomic fragment
extracted from the MGIC ontology [
Figura 2. Adapted fragment from the MGIC Ontology exemplifying MixRig.
These fragment fits the MixRig anti-pattern because Railway Asset is represented as a mixin and its direct subtypes, Station and Railway Lot, are both subkinds, i.e., rigid types. Interacting with the authors of this model, we discovered that terminals always compose railway infrastructures, but lots (empty land areas) are accidental parts of this infrastructure. Thus, Railway Asset was properly characterized as a semi-rigid class, but Railway Lot was mistakenly represented as subkind , for it should have been a role played by a lot when composing a Railway infrastructure.
Name (Acronym) Mixin with Uniform Rigidity (MixRig)) Pattern Roles Mult. Name 1 M ixin 1..*
T ypei Generic Example
Tabela 2. Summary of the MixRig anti-pattern.
Description A mixin class specialized by classes with the same rigidity meta-property, i.e. either all rigid or all anti-rigid.
Allowed Metaclasses mixin
All class stereotypes except mixin Refactoring Plans 1. Not semi-rigid: change the stereotype of M ixin either to a category , if every T ypei is rigid, or to a roleMixin , if every T ypei is anti-rigid. 2. Missing subtype: specialize M ixin with a type (T ype3) that has a rigidity meta-property different from all T ypei. 3. Fix T ypei stereotype: change the stereotype of at least one T ypei (but not all of them) such that the new stereotype embeds a rigidity meta-property different from the remainder T ypei.
The Generalization Set With Mixed Rigidity (GSRig) anti-pattern aims to identify model fragments that suggest the use of multiple specialization criteria within the same generalization set. A GSRig occurrence can be characterized by a generalization set whose common supertype is rigid (i.e. stereotyped as kind , quantity , collective , subkind or category ) and that aggregates generalizations coming from both rigid and anti-rigid types (stereotyped as phase , role and roleMixin ).
A GSRig occurrence can even lead to a logical contradiction, when it contains exactly one anti-rigid type. Such a contradiction arises from the combination of: (i) the rigidity constraints of the subtypes; (ii) the disjointness constraint of the set, which forbids instances of the rigid subtypes to simultaneously instantiate the anti-rigid type; and (iii) the completeness constraint of the set, which requires that every instance of the general type instantiate one of the subtypes. In this case, the only way for an individual to instantiate the anti-rigid subtype at hand would be by doing so since its creation. However, by definition of an anti-rigid type, it is necessary that such an individual possibly ceases to instantiate that type. This is, however, not possible in this case due to the rigidity of the complementary subtypes in that complete generalization set. In summary, this configuration forces the anti-rigid type at hand to classify its instances necessarily, i.e., to be in fact a rigid type.
To determine whether a GSRig occurrence indeed characterizes a modeling error, one should start by double checking the rigidity of the subtypes and fixing them accordingly if there are any mistakes. If after this step all subtypes are either rigid or anti-rigid, the model has been rectified. If that is not the case, one should revisit the common supertype’s intended semantics to assess whether it should be characterized as a mixin , a metaclass that exactly captures common properties shared by rigid and anti-rigid subtypes.
In case the aforementioned steps cannot be used to rectify the model, we suggest modelers to consider the specialization criterion used for each subtype. As we discussed in Section 2, a specialization criteria identifies the “dimension” considered for creating a subtype. For instance, the dimension used to differentiate the classes Child, Adult and Elder is the value of the age quality defined for the class Person. We uncovered throughout our analysis that when multiple dimensions were used to define subtypes within the same generalization set, it was likely for the model to have a problem. Thus, if that is the case, we suggest modelers to: (i) split the generalization set, if the constraints imposed by it are not accurate; or (ii) add a new rigid type as a sibling of the other rigid subtypes and make all anti-rigid subtypes in the generalization set specialize it.
Figura 3. Adapted fragment from the MPOG Ontology exemplifying GSRig.
We exemplify GSRig by means of a fragment of a conceptual model on organizational structures published by the Brazilian Ministry of Planning, Budgeting and Management 3. Fig. 3 depicts the top six types in the model’s taxonomic structure. The root class, Organization, classifies all social entities according to the Brazilian law. Its first refinement distinguishes organizations according to their main activities - public organizations (owned by the government) and companies (owned by the private sector) arise, the former being further refined in non-empresarial public organizations (Non Empresarial P.O.), such as a ministry or a regulatory agency, and state-owned companies, such as 3Original name: Ministe´rio do Planejamento, Orc¸amento e Gesta˜o (MPOG) the “Banco do Brasil” (a government owned bank).
Tabela 3. Summary of the GSRig anti-pattern. Refactoring Plans 1. All subtypes are rigid: transform every AntiRigidi into a rigid class by choosing suitable meta-classes. 2. Missing generalization set: add an extra generalization set (GS2) to group all AntiRigidi classes. 3. Hidden rigid type: add a rigid type (Rigid2) that specializes P arent and generalizes every AntiRigidi in the generalization set.
The generalization set GS2 is the source of this GSRig occurrence. It aggregates the generalization relations coming from State-Owned Company (an anti-rigid type) and Non Empresarial P.O. (a rigid type) to Public Organization (also a rigid type). In fact, this example fits the particular case we previously discussed of a single anti-rigid type (the phase State-Owned Company) in a complete generalization set where all of its complementary types (in this case, only Non Empresarial Public Organization) are rigid. From the description of domain, we can clearly conclude that being a public organization, in the sense of being owned by the government, is a necessary condition for some organizations (e.g. the Ministry of Science and Technology will never be private owned) and contingent condition for others (e.g. a public company that is privatized).
In order to help modelers easily reuse the anti-patterns discussed in this paper to
validate their ontologies, we implemented an anti-pattern management feature in Menthor
Editor 4, an open-source ontology-driven conceptual modeling environment. Following
the strategy adopted in [Sales and
Figura 4. Anti-pattern management support in Menthor Editor.
In this paper, we extended our work on ontological anti-patterns, proposing three new error-prone structures in combination with pre-defined rectification solutions. In particular, the anti-patterns we describe in this paper regard the formalization of taxonomic structures, the “backbone” of every ontology. Therefore, the identification of these antipatterns, their associated rectification plans and the model-based computational tool presented here contribute to the theory and practice of ontology engineering.
In companion publications, we presented anti-patterns (with their
respective rectification plans) identified in in the modeling of material relations
[Sales and
4https://github.com/MenthorTools/menthor-editor
In terms of frequency of occurrence across the analyzed repository, these three anti-patterns occurred in a frequency much lower than some of the other anti-patterns present in our catalog. For example, MixIden and GSRig appeared in 13,51% of the models in which they could possibly occurr, i.e., in which the necessary modeling elements were present. The MixRig appeared in only one of the models that it could possibly occur (7 in total). However, we found out that in 100% of their occurrences they actually represented modeling errors. This is important because, in these cases, one can actually derive syntactic rules to be encoded in the metamodel of the language such that the occurrence of these anti-patterns would be proscribed in OntoUML models. In other words, the occurrence of these anti-patterns would configure a syntactic error rendering the associated model as a non-valid OntoUML model.
Since anti-patterns signal deviations between intended and valid model instances,
and since intended model instances only exist in the mind of domain experts, anti-pattern
discovery is a human-centric activity. Hence, the anti-patterns currently making our
catalog were discovered in a heavily manual process. To overcome this limitation in our
methodology, we intend to study strategies to automate anti-pattern discovery as much
as possible. For instance, we would like to provide mechanisms that could automatically
learn the recurrent correlation between (a) structures in the unintended model instances,
(b) structures in the conceptual models that cause them, and (b) solutions provided by the
conceptual modelers over (b) in order to rectify the unintended situation identified in (a).
Once these strategies are identified and implemented in our computational support, we
intend to extend this tool support to be able to automatically identify these anti-patterns
across different conceptual models in our model repository. A possibly promising path
for investigation in that respect, in the spirit of [
Almeida, J. P. A., Guizzardi, G., and Santos Jr, P. S. (2009). Applying and extending a semantic foundation for role-related concepts in enterprise modelling. Enterprise Information Systems, 3(3):253–277.