Two kinds of ontologies

What is an ontology?

An ontology is a coherent expression of knowledge about some application domain. Ontologies are increasingly expressed in a computer interpretable formalized language, such as in Gellish English. An ontology is an extension of a (taxonomic) dictionary that includes relations of additional kinds between the defined concepts. A taxonomic dictionary is an extension of an ordinary dictionary that includes subtype-supertype relations between all defined concepts.
Organizations may create their own ontology describing their proprietary knowledge. Unfortunately however, only a few standardization organizations and branch organizations have developed generally usable public domain ontologies. This is not at least due to the lack of a general theory about how ontologies should be created. Consequently there is not (yet) a widely agreed and common ontology, nor a common development process. As a consequence, the various ontologies are unnecessary different, whereas they have a lot of conflicting overlap and cannot be simultaneously used nor be integrated. Furthermore, those differences complicate data exchange, hamper interoperability of systems.
One of the root causes of this situation is that there is little awareness of the fact that ontology development typically mingles two kinds of ontologies that should be distinguished.

Two kinds of ontologies

The first kind of ontology should define a common (formalized) language, including the common terminology and its taxonomic dictionary, plus a specification of how to create computer interpretable expressions. Its application domain is ‘language’.
The second kind of ontology should express knowledge about various application domains, using that language.
The creation of the language defining ontology should precede the creation of the application domain knowledge specifying ontology, because the latter should be written using the vocabulary and rules of the first ontology. 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 advocates efforts by branch organizations and institutions to contribute to developments of common language defining ontologies that include also domain terminology and dictionaries for various technical and business domains.

The Gellish ontology

Gellish English is an example of a language defining ontology that is applicable nearly everywhere, because it is a formalization of natural English. Gellish 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 and organizations, including governments. Gellish language defining ontologies are multi-lingual. Gellish.net can provide a separate application domian ontology for businesses that operate in the process industries. The Gellish ontology is defined in a collection of Gellish expressions conform the Gellish Syntax. The Gellish ontology is an extension of and integrated in the Gellish dictionary. The dictionary is therefor also called a taxonomic dictionary-ontology.

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 or ontologies. 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 English and Gellish Dutch.

Knowledge modeling ontologies

When a knowledge modeling ontology is expressed in a pre-defined language defining ontology, then all the terminology that is required for expressing 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 necessarily 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 the subject of another article.

 

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *