Ontologies are models that express formalized knowledge (or requirements) in some application domain. Usually 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 prevent data integration.
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.
This article advocates such a separation as well as an effort by branch organizations and institutions to develop common language defining ontologies that include also domain terminology for various technical and business domains. An example of an initiative to develop a common language defining ontology is Gellish Formal English, which originated in the process industries and in ISO 15926 and another example is the Dutch CB-NL, for the building and civil infrastructure industry in The Netherlands. Both are multi-lingual and are intended to develop into European standards.
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’. 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: http://www.gellish.net).
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 other ontology. This has as advantage that the language defining ontology can be re-used and shared by other people to express their knowledge and to extent the 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.
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 can be composed of shafts, bearings, etc. and that shafts and bearings can have diameters and materials of construction.
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 property relation’ between a ‘physical object’ and a ‘property’. Thus it should also include a definition of the concepts ‘physical object’ and ‘property’, as well as the definitions of the domain specific concepts pump, shaft, bearing, etc., diameter and construction material, etc. To enable semantic verification whether valid expressions are made when using that language, it is important that the language definition also includes that the concepts pump, shaft and bearing are defined as being subtypes of the concept physical object and that diameter and construction material are subtypes of property.
Thus, a language defining ontology includes a dictionary-taxonomy that defines concepts including kinds of relations as well as a specification how expressions can be made.
Note: such a language definition is relevant for and can be shared with any other party that also wants to model knowledge, not only other knowledge about pumps, for example for modeling pump capacities, energy consumption, etc., but also with parties that want to model knowledge about other kinds of things.
A knowledge modeling ontology then does not define additional concepts, but uses the concepts and their definitions, and only specifies that e.g. a pump can (or shall) have as part a shaft and a bearing, etc. and specifies that a shaft and a bearing can (or shall) have a diameter and a construction material.
The subtype-supertype hierarchy of concepts in the language defining ontology enables e.g. that it can be verified whether statements that express knowledge in a knowledge modeling ontology are valid expressions according to the language definition. For example, software can verify whether the statements 'a pump <can have as part a> bearing' and ‘a bearing <can have as aspect a> diameter’ are valid expressions. Software can also verify whether statement contradict each other.