1) I used OntoUML, therefore I built a good ontology!
Sorry, but that is not true! Yes, OntoUML is a highly expressive language which only produces logically and ontologically consistent models. But those two features are not enough to make a good ontology. The ontology must be true to the domain you are modelling, which means two things:
- Using the appropriate meta-category for concepts. Before you start modelling, make an effort to understand the meaning of each stereotype in OntoUML. That will help you classify things appropriately according to the foundational theory. For example, if you want to model the common sense concept of Person, you wouldn't characterise it as an anti-rigid classification, since people cannot stop being people and still exist.
- Checking the possibilities of the model. More often that you think, your model will allow things that you did not foresee. We encourage every modeller to take his/her time validating their ontology.
Of course what makes a good ontology is not only its semantic aspect. For an overview of ontology quality aspects, I suggest reading "Ontology Evaluation", by Denny Vrandecic.
2) Stereotypes are for classes, not relations!
Again, the answer is no! In OntoUML all relations have stereotypes, which imposes particular formal properties (e.g. required existential dependency, minimum cardinality values) and restrict the types os classes they can relate. The only exception is the relation between a class and a Datatype, due to its lack of additional features.
3) Everything is a «formal» relation!
Because it is the least constrained relation in the OntoUML metamodel, ontologists tend to over-use the formal relation to capture every relation that they do not know how to represent. If you only use formal relations, your model will be syntactically correct, but will be semantically poor.
Every constraint included in the OntoUML metamodel has a reason to be there. All of these constraints are the results from one of the many theories from Cognitive Science, Formal Philosophy, Linguistics used to build OntoUML's foundation. Theses constraints are the reason why an OntoUML is logically and ontologically consistent by design. My breaking the language's rules, you are very likely to be producing an inconsistency!
5) Incomplete specification of classes
Reference ontologies are about capturing the meaning of things. What it means for someone to play the student role, or be a member of a group. If you add a class to your OntoUML model but don't characterise what it means to instantiate it, you are not capture the essence of that class, are you?
Think about the following hierarchy. It presents different types of vehicles: car, motorcycle, boat, airplane and truck. By only specifying a Vehicle as a Kind and its subtypes as Subkinds, I all did was to say that vehicle do not change their types through their life. But was is the actual difference between them? What does a car have that differentiates it from a boat or an airplane? If you do not add properties and relations to your subclasses, all the semantics of the term is condensed in the classe's label.
It is very rare to find an ontology accompanied with set of domain constraints. That is the same thing as saying that is very rare find an ontology with accurate domain semantics. As much expressivity as one can include in OntoUML, the visual notation will never be able to express all the different constraints possibilities. Therefore, we strongly suggest to always pay attention if a rule is necessary.
Note that we use the term constraints to refer to either domain invariants (things that should always hold) and derivation rules (rules to calculate data and object values, instantiation and so on).
OntoUML's official rule language is a variation of OCL. If you want to know more about it, click here.
Did you make any of the following assumptions? Want to share your own perceptions? Leave a comment below!
Tiago Prince Sales