User Tools

Site Tools


data_modeling_and_database_design_in_gellish_english

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
Last revision Both sides next revision
data_modeling_and_database_design_in_gellish_english [2018/10/02 01:14]
andries Revision of the first part of the text
data_modeling_and_database_design_in_gellish_english [2018/10/02 14:53]
andries
Line 1: Line 1:
 ===== How to write Gellish enabled software ===== ===== How to write Gellish enabled software =====
-===== 1. Limitations of conventional database design ​=====+==== 1. Limitations of conventional database design ====
  
 Conventional data modelling for any application domain typically results in a domain specific (conceptual,​ logical and physical) data model, also called a scheme. Such a data model documents the requirements and capabilities for storage of data in a database or data exchange messages. Thus it defines the semantic capabilities for expressions of ideas that can be stored in the database or exchanged between systems. \\ Conventional data modelling for any application domain typically results in a domain specific (conceptual,​ logical and physical) data model, also called a scheme. Such a data model documents the requirements and capabilities for storage of data in a database or data exchange messages. Thus it defines the semantic capabilities for expressions of ideas that can be stored in the database or exchanged between systems. \\
Line 6: Line 6:
 Once conventional data models are created, they are fixed and specific for the application domain specific (the Universe of Discourse), whereas software is dedicated to that fixed structure. Thus the storage capabilities of the resulting databases are fixed and limited to the application domain. As a consequence modifications of the storage capabilities are time consuming and costly. \\ Once conventional data models are created, they are fixed and specific for the application domain specific (the Universe of Discourse), whereas software is dedicated to that fixed structure. Thus the storage capabilities of the resulting databases are fixed and limited to the application domain. As a consequence modifications of the storage capabilities are time consuming and costly. \\
  
-===== 2. The Gellish Semantic Modeling Methodology ​=====+==== 2. The Gellish Semantic Modeling Methodology ====
  
 The Gellish Modeling Methodology extents the conventional data modeling methods in various ways: The Gellish Modeling Methodology extents the conventional data modeling methods in various ways:
Line 17: Line 17:
 Below it is described how systems can be created that can import, export and store Gellish data and how flexible user interfaces can be created that allow exchanging a large variety of information without the need to modify their data structure. Below it is described how systems can be created that can import, export and store Gellish data and how flexible user interfaces can be created that allow exchanging a large variety of information without the need to modify their data structure.
  
-== 2.1 Semantic information models in Gellish ==+=== 2.1 Semantic information models in Gellish ​===
  
 The Gellish methodology enables that knowledge and requirements as well as information about individual things (instances) are expressed in the Gellish languages. Gellish then requires that all concepts in the expressions shall be selected from the Gellish dictionary or in case they are not present, they shall ad-hoc be added to that dictionary. This is required in order to ensure the use of a common unambiguous language between application systems that send or receive or store information. Thus standardized concepts and standardized kinds of relations are used to a maximum extent, and concepts and definitions are not reinvented again and again. When concepts or kinds of relations are not available in the Gellish dictionary, then they shall be added as proprietary extensions according to the [[:Proper definition of a concept|rules for extension of the Gellish dictionary]]. The Gellish methodology enables that knowledge and requirements as well as information about individual things (instances) are expressed in the Gellish languages. Gellish then requires that all concepts in the expressions shall be selected from the Gellish dictionary or in case they are not present, they shall ad-hoc be added to that dictionary. This is required in order to ensure the use of a common unambiguous language between application systems that send or receive or store information. Thus standardized concepts and standardized kinds of relations are used to a maximum extent, and concepts and definitions are not reinvented again and again. When concepts or kinds of relations are not available in the Gellish dictionary, then they shall be added as proprietary extensions according to the [[:Proper definition of a concept|rules for extension of the Gellish dictionary]].
Line 40: Line 40:
  
 == 2.1.2 Dictionary extensions == == 2.1.2 Dictionary extensions ==
-If the data modelling ​process (also called the knowledge modelling ​process) identifies concepts or relation types that are required but that do not exist yet in the Gellish English Dictionary, then those concepts and relation types should be added to the Gellish ​English ​Dictionary as proprietary extensions. Such additions shall be compliant with the rules for extension of the Gellish language. ​It is recommended to nominate such extensions for inclusion in the Gellish Dictionary.+If the knowledge modeling ​process (also called the data modeling ​process) identifies concepts or kinds of relations ​that are required but that do not exist yet in the Gellish English Dictionary, then those concepts and kinds of relations ​should be added to the Gellish Dictionary as proprietary extensions. Such additions shall be compliant with the rules for extension of the Gellish language. ​If those extensions are of general use, then it is recommended to nominate such extensions for inclusion in the Gellish Dictionary.
  
-For details of the process to convert ​domain knowledge and requirements ​into a data model it is recommended to use a conventional data modelling methodology,​ such as ORM, in combination with the guidelines on the [[:​Knowledge modeling in Gellish|modelling of knowledge and specifications]]. Here we assume that a data model that is expressed in Gellish English and stored in a Gellish database table is available.+For details of the process to express ​domain knowledge and requirements ​in Gellish ​it is recommended to use a conventional data modelling methodology,​ such as ORM, in combination with the guidelines on the [[:​Knowledge modeling in Gellish|modelling of knowledge and requirements]]. 
  
-== 2.2 A data model stored as instances in a universal Gellish database ​== +=== 2.2 Expressing knowledge and requirements === 
-In conventional ​data modelling it is common practice to convert ​conceptual data model (also called a knowledge ​model) into a database design (a physical data model). This is also possible for the above example knowledge. However, ​it is not necessary ​for a Gellish database, because a Gellish database has a predefined general purpose data structure and consists of tables ​that all have the same standardized ​database table definition (see ‘The Gellish ​Database table definition’). This means that for a Gellish database there is no separate database design required. Table 1 is an example of the core of such a Gellish ​database table, loaded with facts that specify ​the data model with knowledge about pumps.+Conventional ​data modeling starts with the creation of knowledge and requirements ​model (also called a conceptual data model), followed by converting that into a database design (a physical data model) ​or data exchange interface. However, ​in Gellish that is not necessary, because a Gellish database ​or exchange message (file) ​has a predefined general purpose data structure and consists of expressions ​that all have the same standardized ​structure ​definition (see ‘The Gellish ​Syntax and contextual facts' that defines the Gellish Expression format). This means that for a Gellish database there is no separate database design required. All knowledge and requirements about kinds of things that is expressed in Gellish is expressed as binary relations between concepts. Table 1 is an example of Gellish expressions in the Gellish ​Expression format, loaded with statements ​that specify knowledge about pumps. The table shows the core columns, whereas other columns are allowed for expressing e.g. who and when the statement was made, what its status is, etc. Further details about the modeling of knowledge and requirements is given in following sections of this wiki.
  
-This means that the data model that is specified ​in Table 1 does not need to be converted into a database design, but can be directly used to guide the process ​to create instances that can be stored in Gellish ​database table with the same structure (although with other relation types). This is done as is described ​below.+Thus that the knowledge ​that is expressed ​in Table 1 does not need to be converted into a data model or database design, but it can be directly ​stored or exchanged or used in and by Gellish enabled systems for searching knowledge or for guiding ​the process ​of creating expressions with information about individual things or for verifying the consistency with other information about pumps and kinds of pumps. The information about individual things as well as knowledge and requirements ​can all be stored in the same Gellish ​expression format, al sharing ​the same structure (only using different kinds of relations). How such information about individual things (instances) are created ​is introduced ​below.
  
-== 2.3 Creation of instances ​==+=== 2.3 Expressing information about individual products and processes ===
  
-Each fact in a data model that is expressed in Gellish English ​as a relation between concepts can result in "​instances"​ that consist of one or more facts that are expressed in Gellish English as a relation ​between individual things, ​together with classification relations between the individual things and the concepts (classes) that classify them. \\ +Each expression of knowledge or requirements can be used as a guide for creating information about individual products and processes. Expressions about individual things ​consist of a combination of two categories of expressions:​ 1) Expressions ​that are relations ​between individual things, ​and 2) expressions that are classification relations between the individual things and the concepts (classes) that classify them. (The explicit classification relations replace the instantiation of attributes in conventional databases. This illustrates that explicit classification by concepts in a large and even extensible taxonomic dictionary provides a nearly unlimited classification capability.)\\ 
-For example, assume that we want to store facts about a particular centrifugal pump, which is called P-1301. In other words we want to create an individual thing that is classified as a centrifugal pump and we want to create expressions of facts with information about that individual thing. To create that individual thing in Gellish it is required to specify a classification relation between the individual thing P-1301 and the concept (class) that classifies the thing. Such a fact is expressed in Gellish ​English ​as follows: +For example, assume that we want to store ideas about a particular centrifugal pump, which is called P-1301. In other words we want to create an individual thing that is classified as a centrifugal pump and we want to create expressions of ideas with information about that individual thing. To create that individual thing in Gellish it is required to specify a classification relation between the individual thing P-1301 and the concept (class) that classifies the thing. Such a classification ​is expressed in Gellish as follows: 
-  * P-1301 <is classified as a> centrifugal pump (fact 301) +  * P-1301 <is classified as a> centrifugal pump (idea 301) 
-This explicit classification relation ​implies ​that the data model with knowledge about centrifugal pumps as given in Table 1 is applicable for P-1301, including also the inherited knowledge ​facts 101 and 102. \\ +This explicit classification relation ​has as implication ​that the knowledge about centrifugal pumps as given in Table 1 is declared to be applicable for P-1301, including also the inherited knowledge ​about pumps, such as ideas 101 and 102. \\ 
-Note that the data model in Table 1 uses concepts from the Gellish dictionary ​(taxonomy) ​in which a large number of subtypes of pumps are defined. ​For example, it is defined that a line shaft pump is a subtype of centrifugal pump. This means that the knowledge about pumps and centrifugal pumps can also be made applicable for their subtypes, such as for line shaft pumps. Thus the data model enables also to classify P-1301 as any type of pump, including also as a line shaft pump.+Note that the expressions ​in Table 1 use concepts from the Gellish ​taxonomic ​dictionary in which a large number of subtypes of pumps are defined. ​Assume, for example, ​that P-1301 was classified as a line shaft pump. Then that would allocate knowledge about line shaft pumps to P-1301, but the taxonomic dictionary would ensure that the knowledge about pumps and centrifugal pumps remains applicable, because ​it is defined ​in the dictionary ​that a line shaft pump is a subtype of centrifugal pump. Thus the taxonomic dictionary specifies that knowledge about pumps and centrifugal pumps is also applicable for their subtypes, such as for line shaft pumps.
  
-In Gellish ​English there is a distinction between ​relation types that are used to express knowledge (facts about kinds of things) and relation types that are used to express information ​(facts ​about individual things). For example, fact 101 expresses the knowledge that a+Gellish ​makes a distinction between ​kinds of relations ​that are used to express knowledge (ideas about kinds of things) and kinds of relations ​that are used to express information about individual things. For example, fact 101 expresses the knowledge that a
   * pump <can have as aspect a> capacity (fact 101)   * pump <can have as aspect a> capacity (fact 101)
-This knowledge can be used to create a fact with information about P-1301 ​that states ​that P-1301 has a particular capacity, called cap-1301 (say). For the expression of that latter ​fact another relation ​type shall be used in Gellish as follows:+This knowledge can be used to create a statement that expresses ​information about P-1301, stating ​that P-1301 has a particular capacity, called cap-1301 (say). For the expression of that latter another ​kind of relation shall be used in Gellish as follows:
   * P-1301 <has as aspect> cap-1301 (fact 302)   * P-1301 <has as aspect> cap-1301 (fact 302)
  
-In the Gellish Dictionary it is defined which relation ​type shall be used to create information about individual things as a realization of a relation ​type used to express knowledge. Table 2 illustrates which relation types should be used to create realizations of the relation types used in Table 1.+In the Gellish Dictionary it is defined which kind of relation shall be used to create information about individual things as a realization of a kind of relation used to express knowledge. Table 2 illustrates which relation types should be used to create realizations of the relation types used in Table 1.
  
-^Relation type to express knowledge^Name of relation ​type^Relation type to express information^+^Kind of relation ​to express knowledge^Name ​of kind of relation^Kind of relation ​to express information^
 |can have as aspect a |can be realized by a |has as aspect| |can have as aspect a |can be realized by a |has as aspect|
 |can have as part a |can be realized by a |has as part| |can have as part a |can be realized by a |has as part|
-**Table 2, Relation types for product models versus relation ​types for knowledge ​models**+**Table 2, Kinds of relation ​for product models versus ​kinds of relation for expressing ​knowledge**
  
-Furthermore,​ it is a rule in Gellish that every individual thing shall be classified. So, when fact 302 about P-1301 is created this rule implies that P-1301 as well as cap-1301 shall be classified, whereas it is clear that they shall be classified by the concepts (classes) that are the left hand and right hand objects in fact that expresses the knowledge (fact 101). Furthermore ​every individual aspect shall be qualified in such a way that, when the aspect is classified by a subtype of property, then it can be either qualified by a qualitative aspect (e.g. a colour ​can be qualified as ‘red’) or can be quantified on a scale (e.g. a diameter ​can be quantified by a number on a scale as 300 mm). So, knowledge ​fact 101 will result in the following ​facts about the individual object P-1301: \\ +Furthermore,​ it is a rule in Gellish that every individual thing shall be classified. So, when idea 302 about P-1301 is created this rule implies that P-1301 as well as cap-1301 shall be classified, whereas it is clear that they shall be classified by the concepts (classes) that are the left hand and right hand objects in the idea that expresses the knowledge (idea 101). Furthermore, if an individual aspect ​(characteristic,​ quality or property) is qualified, then it shall be qualified in such a way that, when the aspect is classified by a subtype of characteristic, then it can be either qualified by a qualitative aspect (e.g. a color can be qualified as ‘red’) or can be quantified on a scale. ​For example, ​diameter ​D-1 is quantified by a number on a scale as 300 mm. So, knowledge ​idea 101 will result in the following ​ideas about the individual object P-1301: \\ 
-^Language community^UID of left hand object^Name of left hand object^Fact UID^UID of relation ​type^Name of relation ​type^UID of right hand object^Name of right hand object^UID of UoM^Name of UoM^+^Language community^UID of left hand object^Name of left hand object^UID ​of idea^UID of kind of relation^Name ​of kind of relation^UID of right hand object^Name of right hand object^UID of UoM^Name of UoM^f
 |Project A |501 |P-1301 |301 |1225 |is classified as a |130058 |centrifugal pump |  |Project A |501 |P-1301 |301 |1225 |is classified as a |130058 |centrifugal pump | 
 |Project A |501 |P-1301 |302 |1727 |has as aspect |502 |cap-1301 |  ​ |Project A |501 |P-1301 |302 |1727 |has as aspect |502 |cap-1301 |  ​
Line 76: Line 76:
 |Project A |502 |cap-1301 |304 |5025 |has on scale a value equal to |920466 |300 |570423 |mm| |Project A |502 |cap-1301 |304 |5025 |has on scale a value equal to |920466 |300 |570423 |mm|
  
-**Table 3, Gellish facts (instances) ​created on the bases of a Gellish ​knowledge ​facts (a data model)**+**Table 3, Expressions about individual things ​created on the basis of expressions ​of knowledge**
  
 //​**Continue with**// [[:​Development of Gellish enabled software]] //​**Continue with**// [[:​Development of Gellish enabled software]]
data_modeling_and_database_design_in_gellish_english.txt · Last modified: 2018/10/02 15:00 by andries