Gellish enabled software
Gellish enabled software implies software that can read and interpret as well as write Gellish expressions. Such expressions shall comply with the Gellish Syntax that is defined in the Gellish Syntax document, which specifies the flexible tabular Gellish expression format. Gellish enabled software may also include the development of mapping tables to convert non-Gellish data into and from Gellish expressions. This article describes basic characteristics of such software. It is assumed that readers are already familiar with the Gellish Syntax document or with its summary in the relevant Wiki page.
Initializing the Syntax
The Gellish Syntax definition specifies that the number of columns in Gellish expression tables may vary and that the column sequence is not prescribed. To maintain that flexibility it is recommended read the columns and first reorder them conform a sequence that is internal to the software. An example internal expression table definition is given in the file Expr_Table_Def.py of the Communicator reference application on GitHub.
Reading and interpreting Gellish requires first importing the base section of the definition of the Gellish language as defined in the file ‘Formal language definition base’ that itself complies with the Gellish Syntax definition. That file defines the kinds of relations, the kinds of things that are allowed to be related by such relations and the kinds of roles that related things play in such relations. The definition of those concepts form the core of the Gellish language definition. However, the definitions in that file themselves are Gellish expressions that cannot be interpreted without some basic knowledge of the language. This kind of chicken-and-egg problem can only be solved by making that the software aware of the definition of 7 initial kinds of relations. That collection of bootstrapping relations is then used as a start motor for interpreting the definition of all kinds of relations in the base file. The collection consists of the following 7 kinds of relations that are represented by their unique identifiers (UIDs) and are denoted by the following phrases:
– is a kind of
– has by definition as first role a
– has by definition as second role a
– is a base phrase for
– is an inverse phrase for
– is a synonym of”
– is by definition a role of a
Note that these bootstrapping kinds of relations are themselves also defined in the base file.
They can be made known in the software for example by importing them from a bootstrapping file, such as is done in the Communicator reference application file Bootstrapping.py on GitHub.
It is recommended to initialize also other UIDs of concepts as is shown in the above mentioned Bootstrapping file.