User Tools

Site Tools


knowledge_modeling_in_gellish

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
knowledge_modeling_in_gellish [2018/11/01 16:03]
andries [2. Knowledge models]
knowledge_modeling_in_gellish [2018/11/02 21:25] (current)
andries [3.5 Options for subtypes of components]
Line 4: Line 4:
 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 Modeling|product and process modeling]]. Furthermore there is knowledge about requirements (what shall be the case), which we discuss under [[requirements_models|requirements modeling]] and there is knowledge about states of affairs that are by definition the case, which we discuss under [[gellish_domain_dictionary|modeling of definitions]].\\ 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 Modeling|product and process modeling]]. Furthermore there is knowledge about requirements (what shall be the case), which we discuss under [[requirements_models|requirements modeling]] and there is knowledge about states of affairs that are by definition the case, which we discuss under [[gellish_domain_dictionary|modeling of definitions]].\\
  
-====== 2. Knowledge models ​====== +====== 2. What is a knowledge model ====== 
-Knowledge models consist ​of expressions ​of ideas about **kinds** of things and are collections ​of expressions ​of relations between ​kinds of things ​(concepts), whereas product and process models are mainly composed of relations between individual things. ​These different ​relations ​require different kinds of relations, because they express different meanings. \\ + 
-For example, we want to model the knowledge 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: \\+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_management|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 object^Name of kind of relation^Name of right hand object^ ^Name of left hand object^Name of kind of relation^Name of right hand object^
 | pipe | can have as aspect a | internal diameter| | pipe | can have as aspect a | internal diameter|
-This is an example ​of a kind of relation that is suitable for expressing relations between kinds. The kind of relation 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.+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.
  
-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_Models|requirements modeling]]. The following is an example of an expression of an idea about a particular individual pipe P-1 that has an internal diameter of 30 inch. The expressions can be derived from and correspond to the above information about the kind '​pipe'​.  +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. \\
-^Name of left hand object^Name of kind of relation^Name of right hand object^Name of unit of measure^ +
-| P-1| is classified as a | pipe | | +
-| P-1| has as aspect | D-1| | +
-| D-1| is classified as a| internal diameter| | +
-| D-1| is quantified on scale as equal to| 30|inch | +
-The expression of the above information relates the individual pipe P-1 with its individual aspect D-1, using the kind of relation <has as aspect>. The expression is not an expression of generally applicable knowledge and therefore it is usually not classified as knowledge, but it is an expression of an assertion about an individual product. +
- +
-====== 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. \\+
 {{:​knowledge_model-3.jpg?​ 670x480}} \\ {{:​knowledge_model-3.jpg?​ 670x480}} \\
-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 Models|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]]. \\ +The example in the figure, a knowledge model of a roadspecifies 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.  
-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. \\ +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 Models|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]]. \\
-For the specification of designs of a real world objects or materials see the description of [[Product Modeling|product models of individual things]].+
  
 ==== 2.1 Gellish knowledge models versus conventional data models ==== ==== 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: \\+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 integratedwith 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. 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 === === 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. \\+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. 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 === === 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. \\ +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, ​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. \\ +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 engineering ​language and not in IT language.+Therefore, Gellish ​models ​are written in user language and not in IT language.
  
-====== 3. How to create Gellish ​knowledge ​models ​====== +====== 3. How to express ​knowledge ====== 
-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. \\ +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. \\ 
-Extensive guidance on the creation of knowledge models is given in the document [[http://​shop.gellish.net/​shop.html?​page=shop.browse&​category_id=2|Gellish Modeling Methodology,​ Part 3A - Knowledge Modeling]] \\ + 
-A few example ​of specifications of knowledge are given below.+A few examples ​of specifications of knowledge are given below.
  
 ==== 3.1 Create a composition hierarchy ==== ==== 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. \\ +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 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 ​table forms the core of three rows in a Gellish ​Database ​table that specify a little part of a knowledge model with requirements ​for centrifugal ​compressor: \\ +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 object^Name of relation ​type^Min and max right hand cardinalities^Name of right hand object^ +^Name of left hand object^Name ​of kind of relation^Name of right hand object^ 
-| centrifugal compressor | shall have as part a | 1,n | impeller| +| centrifugal compressor | can have as part a | impeller| 
-| centrifugal compressor | shall have as part a | 2,2 | bearing assembly| +| centrifugal compressor | can have as part a | bearing assembly| 
-| bearing assembly | shall have as part a | 1,1 | seal| +| bearing assembly | can have as part a | 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.+Repeated usage of that relation type will result is a decomposition structure of the kind of thing.
  
 ==== 3.2 Define cardinality constraints ==== ==== 3.2 Define cardinality constraints ====
-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. \\ +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 impellersbut 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 cardinalitiesThe term simultaneous ​implies that there may be more components, one after the other, for example due to replacement, but not at the same timeSuch 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: 
-This constraint ​is indicated in a Gellish Database table by two numbers that indicate the minimum and maximum number of components of certain type that are allowed simultaneouslySuch 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.+^Name of left hand object^Name of kind of relation^Min and max right hand cardinalities^Name 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 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 possibilitiesbut as requirements,​ as is discussed ​in the next section.
  
 ==== 3.3 Specify aspects of assemblies and components ==== ==== 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. \\ +For each kind of assembly and for each of the kinds of components in 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. ​If fact a pipe always has a wall thickness, but the wall thickness might not be specified. \\ +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 object^Name of relation ​type^Name of right hand object^+^Name of left hand object^Name ​of kind of relation^Name of right hand object^
 | pipe | can have as aspect a | wall thickness| | 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 ==== ==== 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 methodstesting 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: \\ +In knowledge models it can be specified that objects ​of a particular kind can be (and typically ​is) involved in particular ​kind of activity ​or process, for example as performer or as subject. 
-^Name of left hand object^Name of relation ​type^Name of right hand object^ +For example, it may be specified that a vessel ​can be subject in a pressure test. This a specified as follows: \\ 
-| vessel | shall be subject in a | pressure test|+^Name of left hand object^Name ​of kind of relation^Name 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 ==== ==== 3.5 Options for subtypes of components ====
-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.+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 [[standard_specification_models|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_Models|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 object^Name of kind of relation^Name of right hand object^Name 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| 30|inch | 
 +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]] **//​Continue with//** [[Requirements Models]]
knowledge_modeling_in_gellish.1541084619.txt.gz · Last modified: 2018/11/01 16:03 by andries