Gellish Wiki

Conventional data modeling 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.
In conventional data modelling methodologies, such as ER (Entity-Relationship), ORM (Object-Role Modelling) and others, each data model consists of a definition of the concepts (classes or entity types and attribute types) that are relevant for the application domain, together with relations between those concepts. The concepts are the kinds (classes) that will classify the instances of objects and their aspects, whereas the relations determine the kinds of ideas or facts (instances) that can be stored or exchanged. Such a data model thus defines the structure of the data (the definitions of the database tables and relations between their columns (attributes)).
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.

The Gellish Modeling Methodology extents the conventional data modeling methods in various ways:

• It starts with a predefined language defining ontology, which replaces the data models and adds flexibility (for modifications and extensions) and capabilities for logic and reasoning.
• It makes use of a predefined smart taxonomic dictionary-ontology. This means that concepts and kinds of relations are already defined in such a way that subtype concept inherit knowledge from their supertype concepts and basic knowledge is included. The dictionary allows that users add concepts and kinds of relations whenever needed.
• It defines a universal standardized syntax (in a tabular format) that enables storing and exchanging ideas of any kind.
• It adds the capability for directly expressing ideas about instances of all concepts (kinds/classes) in the dictionary, without the need to define expression capabilities, still allowing for the expression of constraints.
• It provides the flexibility to modify the expression capabilities without the need to regenerate the database or to modify software that operates on the data.

This is achieved by the predefined syntax and semantics of the Gellish family of languages and by expressing information in a Gellish language, such as Formal English. Then there are no data models required for creating database structures or exchange messages (interfaces), because information is always expressed in the same standardized expression format. This means that each database or exchange message can have basically the same structure, being either object oriented or table oriented. This provides a huge reduction of design processes and also means that reusable application software can be created that enables universal storage and retrieval and exchange of ideas of any kind.
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.

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 rules for extension of the Gellish dictionary.

Expressions of knowledge and requirements consist of assertions about kinds of things. Such assertions (or ideas) can be used by application software to create instances, which are typically statements about individual things, or statements about subtypes of the kinds. In other words, application software can create expressions of ideas about individual things or kinds of things on the basis of knowledge or requirements about kinds of things.

For example, knowledge about pumps will be used to guide the process of expressing ideas (information) about individual pumps. The result of such a process of describing an individual pump will be a collection of ideas about the individual pump. But in fact the process of expressing ideas about any individual physical objects is basically very similar, although other kinds of aspects will be relevant for other kinds of objects. For example, all ideas about persons, pieces of software, processes, or statements about relations between them are expressed as relations between things, whereas the nature of those relations are defined by the (standard) kinds of relations that classify the relations.
The information can be presented in graphical form, for example in an ORM schematic drawing, but it can also be presented in the form of collection of Gellish expressions. For example:

Table 1, Information about pumps

All concepts (kinds of things) that are used in Table 1, such as pump, centrifugal pump, impeller, and properties, such as capacity and diameter, are already defined in the Gellish Dictionary and thus their Gellish unique identifiers (the UID’s 130206, 130058, etc.) are selected from that dictionary. Also the kinds of relations are selected from the Gellish Dictionary. The only new things in this table are the ideas, indicated by the idea UID’s, that express the knowledge, except for idea 103, which is not new. Idea 103 is a superfluous duplicate from the idea that already exists in the Gellish Dictionary, because such subtype-supertype relationships are part of the definition of the concepts in the Gellish Dictionary, which makes that the concepts are arranged as a taxonomy.

Note that the taxonomy, the subtype-supertype hierarchy, defines the inheritance of knowledge that is defined for supertype kinds of things to the subtypes kinds of things. This means for this example that idea 103 ensures that the concept ‘centrifugal pump’ inherits from the concept ‘pump’ that a centrifugal pump also can have a capacity, without an explicit specification of that idea.

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 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 modelling of knowledge and requirements.

Conventional data modeling starts with the creation of a 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.

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.

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 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 (idea 301)

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 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.

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, idea 101 expresses the knowledge that a

• pump <can have as aspect a> capacity (idea 101)

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 (idea 302)

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.

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 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:

Table 3, Expressions about individual things created on the basis of expressions of knowledge

Continue with Development of Gellish enabled software