Two kinds of ontologies:
language defining and knowledge modeling
Ontologies are models that express formalized knowledge (or requirements) in some application domain. Typically every organization creates its own ontology on the basis of its own business needs and domain knowledge. Creating your own ontology is often advocated because of differences in business needs. The general theories about how ontologies should be created unfortunately have not
(yet) resulted in an agreed and common ontology development process. As a consequence, the resulting ontologies are unnecessary different, whereas those differences complicate data exchange, hamper interoperability of systems and causes that data integration is unnecessary cumbersome.
One of the root causes of this situation is that there is little awareness of the fact that ontology development typically mingles two types
of ontologies that should be distinguished: one ontology should define a (formalized) language, including the domain terminology and the other should model the domain knowledge, using that language. The creation of the language defining ontology should precede the creation of the domain knowledge specifying ontology, because the latter should be written conform the conventions of the first one. Furthermore, there is no reason why one language defining ontology could not be shared between various parties.
This article advocates such a separation between ontologies and it also advocates an effort by branch organizations and institutions to develop common language defining ontologies that include also domain terminology for various technical and business domains.
Gellish Formal English is an example of a language defining ontology that is applicable nearly everywhere, because it is a formalization of natural English. Gellish Formal Dutch (Formeel Nederklands) is a Dutch version of the same ontology. It originated in the process industries and in ISO 15926 and ISO 16354 and is extended to serve other businesses, organizations, including governments. Gellish language defining ontologies are multi-lingual. Gellish.net can provide a separate knowledge modeling ontology for businesses that operate in the process industries.
Language defining ontologies
It should be noted that a language defining ontology will logically obey a number of generic rules and concepts that are common to every
human language. Thus every human language has mechanisms to express a number of shared semantic concepts. For example, in every language it can be expressed that things can be composed of components and that activities can be performed by actors. Thus every language defining ontology will include the concepts ‘composition relation’ and ‘performer relation’ (and their subtypes). This implies that every language defining ontology for a particular domain will consist of a generic part, which is application domain independent, and a domain specific part that will include the domain terminology. In other words the language defining ontology includes the vocabulary and the dictionary that is required by the knowledge modeling ontology. The common generic elements in language defining ontologies indicate that there is an opportunity for integrating the common parts of the language defining ontologies into a generic formalized language that can be used in combination with various domain ontologies. Such an integration is realized
e.g. in Gellish Formal English and Formal Dutch (see: https://www.gellish.net).
Knowledge modeling ontologies
When a knowledge modeling ontology is expressed in a pre-defined language defining ontology, then all the terminology that is required
to express the knowledge should be included in the language defining ontology (the language definition). Thus the domain terminology is a given for the knowledge modeling ontology. This means that the knowledge modeling ontology only specifies relations between concepts that are defined in the language defining ontology. This has as advantage that the language defining ontology can be re-used and shared among people as a common vocabulary and semantics for expressing their knowledge in a mutually interpretable way. This stimulates extending the common language defining ontology when required. Thus cooperation between parties will create benefits of growing towards a common language, without merging the knowledge modeling ontologies. This will lead towards simplified data exchange, interoperability of systems and enables data integration.
Example: a pump ontology
The following example illustrates the separate development of the two kinds of ontologies.
Assume we want to develop an ontology with knowledge about pumps. That ontology should model the knowledge e.g. that pumps have capacities and can be composed of shafts, bearings, etc. and that shafts and bearings can have diameters and materials of construction, etc.
A language defining ontology that is suitable for that knowledge domain should include a definition of a ‘composition relation’ between ‘physical objects’ and a ‘possession of characteristic relation’ between a ‘physical object’ and a ‘characteristic’. Thus it should also include a definition of the concepts ‘physical object’ and ‘characteristic’, as well as the definitions of the domain specific concepts pump, capacity, shaft, bearing, etc., diameter and construction material, etc. Software can perform a semantic verification, which includes a.o. that it can verify whether expressions are valid according to the language definition. To enable such a verification, it is important that the language definition also includes that the concepts pump, shaft and bearing are subtypes of the concept ‘physical object’ and that capacity, diameter and construction material are subtypes of the concept ‘characteristic’. This implies e.g. that the statement ‘a bearing can have as characteristic a diameter’ is verifies as being a valid expression, whereas the expression ‘a diameter can have as characteristic a bearing’ can be detected as incorrect. Note that this part of a language definition can be shared with any other party that also wants to model knowledge about pumps, because such a language defining ontology does not include proprietary know how. For example it can be shared for modeling pump capacities, energy consumption, etc., but also with parties that trade such components or want to model knowledge about other equipment, e.g. about compressors.
A knowledge modeling ontology then does not define the above concepts, but it uses those concepts and their definitions, and it only specifies knowledge or requirements. For example, it may specify that a pump can (or shall) have as part a shaft and a bearing of a particular kind, etc. and it specifies that a shaft and a bearing can (or shall) have a diameter and a construction material.
Product and process models
Finally product and process models that model information about individual products (objects) and processes and activities can use both the language definition ontology as a common language for expressing information as well as the knowledge modeling ontologies for deriving knowledge and requirements for creating (designing) new products and processes and for verification of information on their compliance with the expressed knowledge and requirements.
But product and process modeling is not the subject of this blog.