User Tools

Site Tools


Knowledge modeling

1. Distinction between knowledge and information

With knowledge modeling we mean the modeling of general knowledge about kinds of things, whereas with information modeling and product modeling we mean the modeling of specific facts about individual things. Therefore, we distinguish between knowledge modelling and information modeling or product modeling. As a consequence knowledge models are composed of relations between kinds of things (concepts), whereas information models or product models are mainly composed of relations between individual things. These different relations require different kinds of relation types, because they express a different meaning. So, modeled knowledge consists of expressions of facts about kinds of things, whereas modeled information about facilities, components and designs consists of expressions of facts about individual things.
For example, we want to model the knowledge that a pipe generally has an internal diameter. Such knowledge can be expressed in Gellish English by specifying a relation between the concepts 'pipe' and 'internal diameter', using a relation type <can have as aspect a>, so that the expression becomes:

Name of left hand objectName of relation typeName of right hand object
pipe can have as aspect a internal diameter

This is an example of a relation type that is suitable to express relations between concepts (kinds of things). The relation type expresses the meaning that for individuals of the kind 'pipe' it is known that information about (the value of) the aspect 'internal diameter' can be present.

Another relation type could also be used, for example in the expression pipe <shall have as aspect a> internal diameter. This is an example of another relation between kinds of things that is called a requirement specification, as are the components of requirements models.

In contrast with the expression of knowledge or requirements, the following is an example of an expression of a fact about an individual object, as can be part of an information model. For example, the fact that a particular pipe p-1 has an internal diameter of 30 inch. This is a fact about an individual pipe. The expression of such information in Gellish English relates an individual pipe p-1 with its individual aspect d-1, using the relation type <has as aspect>. The expression thus becomes p-1 <has as aspect> d-1. The expression of such a fact is not an expression of generally applicable knowledge and therefore its creation is not classified as knowledge modeling, but it is an expression of a fact about an individual product and is therefore called product modeling or in general 'information modeling'. The integration of various product models in a larger facility is called a facility model.

2. What is a knowledge model

The result of a knowledge modelling activity is a knowledge model. A knowledge model is a computer interpretable model that specifies the components, the properties and the behaviour of a kind of thing, including various options for variations within the constraints of the definition of the kind of thing. This means that a knowledge model is a specification in terms of data in a database and not so much a textual description (in a natural language). However, pieces of text are allowed in Gellish English as elements in a knowledge model.
The following figure is an example of a knowledge model of a road. A more extensive example of a knowledge model as well as of a product model of a road is given in a document in the download area of this website.
The example in the figure, a knowledge model of a road specifies characteristics of a road in general. The various facts (relations) are included as an element of the collection of facts that is the knowledge model (only two of those <is an element of> relations are shown). Knowledge models typically do not specify all design opions, nor make particular choices between options, because usually there are too many varieties and too many kinds of components that can be part of an assembly of a particular kind. However, when we model a general specification of a kind of thing, such as is provided for example in a particular standard design, then the result will be a knowledge model that is much more specific and has much less variety of options and has more constraints than a model of that kind of object in general. Such a Standard Specification Model is a special kind of knowledge model, because it does not intent to specify the knowledge about the kind of object in general, but it makes particular choices without describing other options. In other words such a standard specification model specifies a particular subtype. Standard specification models are created in the same way as Requirements Models.
This sectionis about the creation of knowledge models. This means that this section describes knowledge facts about kinds of things or concepts. Such knowledge facts are expressed as relations between concepts.
For the specification of designs of a real world objects or materials see the description of product models of individual things.

2.1 Gellish knowledge models versus conventional data models

Gellish knowledge models are different from conventionl knowledge models. They model the same knowledge ina different way. Gellish knowledge models have flexible and open data structures, which makes them extensible and enables their integration with other models. For example, a compressor model can be integrated with a model of a lubrication system without the need to extent the data structure. Conventional data models, on the otherhand, are knowledge models with fixed data structures. The difference can be explained as follows:
To create knowledge models that are computer interpretable it is required to express the knowledge in a formal structure or a formal language. Formal means that the concepts are unambiguously (formally) defined and that the relations between the concepts are also formally defined so that the expression becomes computer interpretable. To achieve such a computer interpretability there are two kinds of modeling methods.

2.1.1 Conventional knowledge models

Conventional modeling methods specify how to develop a fixed data structure or meta model of related concepts. Such a data model acts as a template in which all further knowledge has to be filled-in as instances. The advantage of such a data model or template is that it is a dedicated model of the application domain and the rules for interpretation of the data are defined on beforehand. The disadvantage of such a data model is that the model is a rigid framework that only allows to store data and types of facts that are predefined by the data model. Whenever the scope of the database changes and other data need to be added it is required that the data model and thus the database has to be redesigned. Such a redesign, with the associated changes of the application software is not a simple excercise. Furthermore, the dedicated concepts are defined on an ad hoc basis and are not part of a common language which dictionary is shared with others in the public domain.
A consequence of such conventional dedicated data models is that there are many different databases, knowledge bases and domain ontologies each of which fits into its own meta model. However, because of the differences between those data models it is not possible to integrate data from different databases, nor to integrate the various knowledge models and the various ontologies remain isolated.

2.1.2 Gellish knowledge models

A Gellish knowledge model is a collection of facts that are expressed as relations between concepts. The large variety of available relation types and its extensibility in combination with the unlimited number of facts, enables that any knowledge can be included in a Gellish knowledge model. Furthermore, Gellish English is itself an extensible knowledge model of the Gellish English language, so that any knowledge model forms an integrated whole with that language definition. In conventional modeling there is a strong separation between the data model (expressed in a dedicated 'modeling language') and the knowledge model which consists of instances of the data model. In Gellish modeling there is not such a separation, but the langauge definition and the model are expressed in the same language, just as in natural languages. This makes a Gellish knowledge model extensible and therefore the Gellish modeling method comes close to the capabilities of natural languages.
Furthermore, to create a knowledge model (or conceptual data model) in Gellish English it is not required to define new concepts (such as entity types and attribute types or object types), because a Gellish knowledge model selects its concepts from the Gellish English Dictionary as its common language.
Therefore, Gellish Models are written in engineering language and not in IT language.

3. How to create Gellish knowledge models

A knowledge model about a kind of thing consists of a coherent collection of facts about that kind of thing. For example, a collection of facts that specify knowledge about a centrifugal compressor. Each fact in such a collection specifies 'something about a compressor that can be the case or that normally is the case'. Each such fact about a kind of thing can be expressed in Gellish English as a relation between the kind of thing and another kind of thing (typically a component or a process in which such a kind of thing can be involved). Such a fact is expressed by a relation between kinds of objects that are selected from the Gellish English Dictionary or that should be added by private extensions of the dictionary.
Extensive guidance on the creation of knowledge models is given in the document Gellish Modeling Methodology, Part 3A - Knowledge Modeling
A few example of specifications of knowledge are given below.

3.1 Create a composition hierarchy

The core of the knowledge model is formed by a (de)composition hierarchy, also called an assembly structure. Therefore, the base type of relationship in a knowledge model is the composition relation. Each composition relation defines a relation between an assembly and one of its components.
For example, the following table forms the core of three rows in a Gellish Database table that specify a little part of a knowledge model with requirements for a centrifugal compressor:

Name of left hand objectName of relation typeMin and max right hand cardinalitiesName of right hand object
centrifugal compressor shall have as part a 1,n impeller
centrifugal compressor shall have as part a 2,2 bearing assembly
bearing assembly shall have as part a 1,1 seal

The kind of relationship (or relation type) is a conceptual part-whole relation that is expressed by the phrase in Gellish English as 'shall have as part a', just as in natural English. Repeated usage of that relation type will result is a decomposition structure of the kind of thing.

3.2 Define cardinality constraints

A particular kind of assembly may have a varying number of components of a particular kind. For example, a compressor may have no impeller or many impellers, whereas a centrifugal compressor shall have at least one impeller. Such a constraint can also be context specific, because in some context the minimum or maximum number of components may differ from the situation in other contexts. For example, a particular manufacturer may only fabricate single impeller compressors.
This constraint is indicated in a Gellish Database table by two numbers that indicate the minimum and maximum number of components of a certain type that are allowed simultaneously. Such constraints are called minimum and maximum simultaneous cardinality constraints. (Simulteneously implies that there may be more components, one after the other, for example due to replacement.) The number n for a maximum indicates that the maximum number is unlimited, as indicated in the above table.

3.3 Specify aspects of assemblies and components

For each assembly and for each of the components in the knowledge model it shall be further specified which aspects it shall or can have and what the allowed values for those properties and qualities are.
The following table is an example of a specification that a pipe can have a wall thickness. If fact a pipe always has a wall thickness, but the wall thickness might not be specified.

Name of left hand objectName of relation typeName of right hand object
pipe can have as aspect a wall thickness

3.4 Specify knowledge about processes and activities in which objects are involved

Kinds of objects are typically involved in particular kinds of activities. Typically knowledge or requirements can be provided about manufacturing methods, testing and maintenance activities for kinds of things. For example, it may be specified that a vessel shall be subject in a pressure test. This a specified as follows:

Name of left hand objectName of relation typeName of right hand object
vessel shall be subject in a pressure test

3.5 Options for subtypes of components

A knowledge model or a general specifications model usually will allow flexibility to select various types of components from a list of possible subtypes. For example, the Gellish English Dictionary specifies that there are many types of bearing, such as radial bearing, axial bearing, roller bearing, ball bearing, etc. Each of those subtypes may have different components and different characteristics.

Continue with Requirements Models

knowledge_modeling_in_gellish.txt · Last modified: 2017/08/11 15:10 (external edit)