Our goal with this blog is to share our experiences regarding Ontology-driven Conceptual Modeling, in general, and OntoUML, in particular. We will write about many different topics, varying from tutorials of OntoUML and its foundations, to our own research advances, because here at Menthor, we are not only software developers, we are also scientists.
We encourage you to interact with us and to provide your own views on the topics covered in this blog. A good and healthy debate is always welcome!
So, maybe you are still wondering why we named our blog "The Humble Ontologist". In fact, we borrowed the name from Giancarlo Guizzardi, OntoUML's author, who adapted the expression from E.W.Dijkstra's famous Turing Award Lecture "The Humble Programmer" in 1972. In Dijkstra original lecture, he makes argues that one should approach the programming task with a couple things in mind, the full appreciation of its intrinsic difficulty and the modesty to accept the limitations of our minds. By accepting these two assertions, we can understand that, to deal with such complexity, we need sophisticated techniques supporting throughout the process.
In the paper Theoretical Foundations and Engineering Tools for Building Ontologies as Reference Conceptual Models, Guizzardi applied Dijkstra's reasoning to the task of building large ontology-driven conceptual models. These complexities come from various places, such as the modeling language we are using, the context in which we are developing the ontology, the people involved in the endeavour, the quality requirements of the resulting ontology, and even the domain itself being modeled.
To be a little more explicit, let us consider modeling languages. Needles to say that they all carry their own complexities. Some more than others, but they all have their ontological commitments, which we must be very aware when using them. For instance, if we are modeling using BMPN, we will specify events, tasks, gateways, data objects and so on. We will need to know what is the real world meaning of these elements, in order to build proper models. We will also need to know how these elements can be combined to produce consistent models, which may be not all that intuitive.
We can find another example considering the how and why we build ontologies. Imagine that you were hired to build an ontology to integrate multiple systems owned by an organization. To do that, you will have to uncover the worldview of each system (sometimes hidden in the depth of the legacy code) and then align them. It gets more complicated when you remember that often, these systems were developed by different people, in different times, using various technologies.
Therefore, by actings as a humble ontologist, one would surround herself with as many tools as possible to help her manage the intrinsic complexities of building these formalizations. In fact, the whole OntoUML approach is driven by that philosophy. Besides the modeling language itself, which was designed in compliance with a foundational ontology, it comes with support for model verification, model validation via visual simulation, design patterns and anti-patterns, model verbalization and code generation. All of which you can find our tool, Menthor Editor.
We called our blog "The Humble Ontologist" because that is our whole philosophy. We build tools to make the life of the working ontologist easier, so he can be more efficient and build models as good as they need to be.
That is it for today. Please feel free to leave a comment below.
Tiago Prince Sales