User Tools

Site Tools


knowledge_modeling_in_gellish

Knowledge modeling

1. Categories of knowledge

With knowledge modeling we mean the modeling of possibilities for kinds of things, in other words about what can be the case. There are other categories of knowledge. For example knowledge about the state of affairs of individual things (which is the case), which we discussed under product and process modeling. Furthermore there is knowledge about requirements (what shall be the case), which we discuss under requirements modeling and there is knowledge about states of affairs that are by definition the case, which we discuss under modeling of definitions.

2. What is a knowledge model

The result of a knowledge modeling activity is 'modeled knowledge'. When such modeled knowledge is a coherent computer interpretable collection of expressions about a particular kind of thing we can call the collection a knowledge model. Knowledge is expressed as relations between kinds of things (concepts) that specify possibilities (what can be the case) for things of a particular kind. For example, knowledge may be specified about the possible kinds of components of a kind of thing and its possible kinds of properties and the possible kinds of properties of the kinds of components. The knowledge may also include options for values within the constraints of the definition of the kind of thing. This means that a knowledge model is a specification in the form of formal expressions and not so much as textual descriptions (in a natural language). However, it is possible to express knowledge by relating objects to pieces of text that are included as 'information objects' in a knowledge model and it is also possible to relate an object to a document (as is described in the section about document modeling.
Thus knowledge models are supposed to express possibilities about kinds of things, whereas product and process models express states of affairs about individual things. The latter models are thus mainly composed of relations between individual things. The relations between individual things express different meanings from relations between kinds of things in knowledge models.
An example of knowledge is the expression that a pipe generally has an internal diameter. Such knowledge can be expressed in Gellish by specifying a relation between the concepts 'pipe' and 'internal diameter', using the kind of relation 'can have as aspect a', so that the expression becomes:

Name of left hand objectName of kind of relationName of right hand object
pipe can have as aspect a internal diameter

In the above example a kind of relation is used that is suitable for expressing relations between kinds. The kind of relation 'can have as aspect a' expresses the meaning that for individuals of the kind 'pipe' it is known that information about (the value of) an aspect of the kind 'internal diameter' can be present as information about the individual pipes.

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 in a road network is given in a textual document in the download area of this website, which is accompanied by a file with the corresponding Gellish expressions.
knowledge_model-3.jpg
The example in the figure, a knowledge model of a road, specifies characteristics of a road in general. The various expressions are included as an element of the collection of expressions that forms the knowledge model (only two of those <is an element of> relations are shown). Knowledge models typically do not specify all design options, 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. A special category of knowledge models are the general specifications of kinds of things, such as are 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 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 of a kind. Standard specification models are therefore usually modeled in the same way as Requirements Models.

2.1 Gellish knowledge models versus conventional data models

Gellish knowledge models are different from conventional knowledge models. They model the same knowledge in a 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 combined (and thus integrated) with a model of a lubrication system without the need to extent the data structure ot to modify the content. Conventional data models, on the other hand, 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 exercise. 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 assertions that are expressed as relations between concepts. The large variety of available relation types and its extensibility in combination with the unlimited number of expressions, enables that any knowledge can be included in a Gellish knowledge model. Furthermore, Gellish is itself an extensible knowledge model of the Gellish family of languages, 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 language 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, creating a knowledge model (or conceptual data model) in Gellish does not require to define new concepts (such as entity types and attribute types or object types), because a Gellish knowledge model selects its concepts and vocabulary from the Gellish dictionary as its common language.
Therefore, Gellish models are written in user language and not in IT language.

3. How to express knowledge

A knowledge about a kind of thing consists of a coherent collection of possibilities about that kind of thing. For example, a collection of expressions 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 expression about a kind of thing can be expressed in Gellish 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 an expression by a relation between kinds of objects that are selected from the Gellish Dictionary or that should be added by private extensions of the dictionary.

A few examples of specifications of knowledge are given below.

3.1 Create a composition hierarchy

The core of the knowledge model of a kind of assembled object is usually the specification of the possible composition of such an assembly. Thus specifying the various possibilities of a conceptual (de)composition hierarchy, also called a conceptual assembly structure. The term conceptual indicates that it classifies relations between concepts (kinds). Thus, the base kind of relation in a knowledge model is the conceptual composition relation, typically using the phrase 'can have as part a' for denoting the kind of relation in English, just as in natural English. Each possible composition relation defines a relation between a kind of assembly and one of its kinds of components.
For example, the following expressions forms the core of three rows in a Gellish expression table that specify a little part of a knowledge model with possibilities for centrifugal compressors:

Name of left hand objectName of kind of relationName of right hand object
centrifugal compressor can have as part a impeller
centrifugal compressor can have as part a bearing assembly
bearing assembly can have as part a seal

Repeated usage of that relation type will result is a decomposition structure of the kind of thing.

3.2 Define cardinality constraints

Assemblies of a particular kind may have various numbers of components of a particular kind. For example, a centrifugal compressor shall have at least one impeller and can have any number of impellers, but a compressor in general may have no impeller at all (for example when it is a reciprocating compressor). The minimally and maximally possible simultaneous right hand object for one left hand object is called the minimum and maximum simultaneous right hand cardinalities. The term simultaneous implies that there may be more components, one after the other, for example due to replacement, but not at the same time. Such cardinalities are specified as two values, separated by a comma and a space (, ) in a separate column in the Gellish expression format. Thus a minimum and maximum right hand cardinality expresses that one object that is classified by the left hand kind shall have a number of components that are classified by the right hand kind between the minimum and maximum number. When no cardinalities are specified, then the default is (0, n). The use of right hand cardinalities is illustrated in the following extension of the previous table:

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

The above expressions specify that a centrifugal compressor can have any number of impellers, indicated by the value 'n', but it shall have at least one impeller. And according to this statement each centrifugal compressor has two bearing assemblies, whereas each bearing assembly has just one seal. Whether the above specified minimum and maximum numbers are absolute constraints is a question for compressor specialists and bearing specialists. Often the actual possibilities are wide, whereas in a particular context the constrains are narrower. For example, a particular manufacturer may only fabricate single impeller compressors, so that in the context of his company the maximum number of impellers is 1. Such context dependent narrower constraints should then not be expressed as constraints on possibilities, but as requirements, as is discussed in the next section.

3.3 Specify aspects of assemblies and components

For each kind of assembly and for each of the kinds of components in a knowledge model it can be further specified which aspects, being characteristics, properties and qualities it can have and it may be specified what the possible values for those properties and qualities are. (properties being characteristics that can be quantified on a scale and qualities being characteristics that can be qualified by a value that is denoted by a textual value (such as 'red' or 'steel').
The following table is an example of a specification that a pipe can have a wall thickness. In fact a pipe always has a wall thickness, but the wall thickness might not be specified. Therefor the Gellish phrase 'can have as aspect a' denotes a kind of relation that specifies that it can have or has by definition an aspect of the specified kind and that aspect may be included in the model.

Name of left hand objectName of kind of relationName of right hand object
pipe can have as aspect a wall thickness
pipe can have as aspect a material of construction
pipe can have as aspect a nominal diameter

It should be noted that the definition of the used kind of relation specifies what the kind of left hand and right hand object shall be. In this example the right hand object a subtype of 'aspect'. Note that for expressions that use the above kind of relation. The kind of relation may be more specialized and thus constrain the possible values to properties with values that are formed by numbers on a scale or by nun-numeric values, such as colors.
Note that in conventional data modeling nearly everything is allowed to be an 'attribute' of an object, but in Gellish the kind of relation expresses more precisely what kind of thing may play the role of (left hand and) right hand object in a particular kind of relation.

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

In knowledge models it can be specified that objects of a particular kind can be (and typically is) involved in a particular kind of activity or process, for example as performer or as subject. For example, it may be specified that a vessel can be subject in a pressure test. This a specified as follows:

Name of left hand objectName of kind of relationName of right hand object
vessel can be subject in a pressure test

Furthermore, it is possible to specify further detailed knowledge about various kinds of activities and processes, such as manufacturing methods, testing and maintenance activities. Often such kinds of activities or processes are especially for particular kinds of objects that are involved in activities or processes of those kinds. In many cases users do not specify generic knowledge about kinds of activities or processes, but they may specify requirements, as are discussed in the following section.

3.5 Options for subtypes of components

As the Gellish Dictionary is a taxonomy that specifies known subtypes of kinds of things, a specification of a possible kind of component implies that such a component might be more precisely classified as a subtype of the specified kind of component. Thus a knowledge model usually allows for flexibility for selecting any kinds of component from a list of possible subtypes of the specified kind of component. For example, the Gellish Dictionary specifies that there are many kinds of bearings, such as radial bearing, axial bearing, roller bearing, ball bearing, etc. Knowledge about each of those subtypes may specify that have different kinds of components and different characteristics. It may even be that manufacturer's models from their catalogues are included in (an extension of) the dictionary as further subtypes, whereas knowledge about those subtypes are specified as well. Modeling of manufacturer's models and standard product specification such as in (intenational) standards is further discussed in the section about product types.

4. Using knowledge for creating individual things

Note that the expression of knowledge (and requirements and definitions) about kinds of things uses different kinds of relations than the corresponding expression of information about individual things, although they can all be integrated into one integrated semantic network. For example, the above kind of relation 'can have as aspect a' corresponds in information about individual things to the kind of relation 'has as aspect'. The expressions of knowledge can be used by software to guide the specification of individual things. To enable such an application, Gellish contains relations between the two kinds of relations, as is further described in requirements modeling. The following is an example of an expression of an idea about a particular individual pipe P-1 that has a nominal diameter of 30 inch. The expressions can be derived from and correspond to the above information about the kind 'pipe'.

Name of left hand objectName of kind of relationName of right hand objectName of unit of measure
P-1 is classified as a pipe
P-1 has as aspect D-1
D-1 is classified as a nominal diameter
D-1 is quantified on scale as equal to 30inch

The first classification relation expresses the P-1 is a pipe and thus the knowledge about the concept 'pipe' (and its supertypes!) is applicable to P-1. Thus software can suggest that P-1 might have an nominal diameter and may generate a proposal its possible values and for the other three expressions.

Continue with Requirements Models

knowledge_modeling_in_gellish.txt · Last modified: 2018/11/02 21:25 by andries