Differences

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

--- gellish_databases [2011/11/18 20:01]
peterbuenk
+++ gellish_databases [2018/10/31 16:27] (current)
andries [1. Universal Semantic Databases]
@@ Line 1: / Line 1: @@
-====== 1. Gellish Database Design ======
+====== 1. Universal Semantic Databases ======
-Each Gellish Database consists of one or more Gellish Database tables. Each of those Gellish Database tables has basically the same structure and is standardised and is application system independent. This is different from conventional databases that usually have proprietary data structures, and that have database tables that are all different. Each of the Gellish Database tables shall contain at least the obligatory columns of one of the subsets of columns that are defined in the Gellish Database Definition document, which is summarised below. \\
+Gellish is a family of universally applicable languages. The standardized structure or syntax of Gellish expressions is system independent and universally applicable, thus allowing for the expression of any idea. This implies that Gellish enabled databases or data exchange messages (interfaces) are not application specific and thus they do not require the development of dedicated data models, nor dedicated database designs. This means that Gellish enables defining universal semantic databases and interfaces and enables that software can be reused in other applications. This is due to the Gellish syntax or universal data model and the standardization of the concept definitions and vocabulary.\\
-The content of Gellish Database tables shall be compliant with the grammar and the dictionary of the formal Gellish English language (or a Gellish variant in any other natural language). The standardised tables, combined with the formal Gellish language enables to combine an arbitrary number of Gellish Database tables into one Database. Furthermore, such a database might be centralised, but can also be a //**distributed database**//. This also enables to combine the results of a [[:Querying a Gellish English database|Gellish query]] to various //independent// data stores, which then act as a distributed database. \\
+The [[https://github.com/AndriesSHP/Gellish|Gellish Communicator project]] on GitHub is an example of such a universal Gellish database system.
-The various Gellish Database tables all have the same core of column definitions. Apart from that core, the tables may also have one or more of the optional columns. Preferred collections of columns are defined in standard Gellish database table subsets.
+The uniform data structure or syntax of the expressions is described in [[gellish_expression_format|the previous section]]. \\
-A Gellish Database may be implemented in various formats. It can be in the form of an SQL database, or in XML, or even in XLS (the form of Excel spreadsheet tables).
 ====== 2. Limitations of conventional databases ======
-Conventional databases typically consist of many tables, each of which is composed of a number of columns. The definition of those tables and columns determine the storage capabilities of the database, whereas the relations between the columns define the kinds of facts that can be stored in such a database. Those columns and relations determine the database structure that defines the expression capabilities of the database. Similar rules apply for the ''structure'' of data exchange files and thus for the information that is exchanged in electronic data files. \\
+Conventional databases typically consist of many tables, each of which is composed of a number of columns. The definition of those tables and columns determine the storage capabilities of a database, whereas the (implied and explicit) relations between the columns define the kinds of facts that can be stored in such a database. Those columns and relations determine the database structure that defines the expression capabilities of the database. Similar rules apply for the //structure // of data exchange files and thus for the information that is exchanged in electronic data files and interface messages. \\  This conventional database technology has some major constraints:
-This conventional database technology has some major constraints:
-  * When data was not covered during the database design and thus is not included in the data model, then such data cannot be stored in the database nor exchanged via such a data file structure.
-  * Different databases have different data structures, which causes that data in one database cannot be integrated with data from other databases nor exchanged between databases without dedicated data conversion.
-  * A database modification or extension requires redesign of the database structure, modification of software and data conversion, which makes it a relatively complicated and costly exercise.
-Another characteristic of conventional databases is that there are hardy international standards available or used for the ''content'' of the databases, being the data that is entered by its users. This typically means that local conventions are applied to limit the diversity of data that may be entered in those databases. As local conventions usually differ from other local conventions this has as disadvantage that data that are entered in one database cannot be compared or integrated with data in other databases, even if those database structures are the same and even if the application domain of the databases is the same. For example, within a company there may be various implementations of the same system in various sites for the storage of data about equipment, whereas for example the performance data about the same type of equipment still cannot be compared with the performance data in another location, because the equipment types have different names and the properties are also different.
-====== 3. Characteristics of a Gellish Database ======
-A Gellish database does not have the semantic limitations that conventional databases have, because of the flexible and open Gellish language and because of its standard universal data structure (grammar), which is simple, computer and human interpretable. A Gellish database consists of one or more database tables, each of which has the same table structure (column definitions). The fact that those Gellish Database tables are standardised and universally applicable makes a Gellish database application independent. A standardised Gellish database table is universally applicable because it enables the application of the following two fundamental principles:
-  - Explicit classification of individual things or explicit specialisation of classes, with an unlimited number of classes in a dictionary.
-  - The Gellish database table enables to store any kind of object; because any individual object can be introduced by specification of an explicit classification relation between the object and a class, whereas classes (kinds of objects or concepts) can be selected from the very large number of classes that are already defined in the Gellish English Dictionary and if the proper class is not available it can be added by specification of a subtype-supertype relation with a direct supertype of the new class. This is fundamentally different from conventional databases that predefine the object types (classes) about which information can be stored by defining a limited number of entity types and attribute types in a fixed data model.
-  - Explicit classification of relations (facts), by an extensible unlimited number of standardised relation types.
-  - The Gellish database table enables to store any kind of fact about any kind of object, because any fact is expressed by a relation, whereas those relations are explicitly classified by relation types that can be selected from the standardised relation types that are defined in the Gellish Dictionary or by relation types that are added to the dictionary as proprietary extensions. This is fundamentally different from conventional databases that predefine a fixed and limited number of relation types between the columns in the database tables (whereas unfortunately those relation types are usually defined only in an implicit way).
-As a consequence, a Gellish database does not need to be modified or extended when the scope of an application changes and facts from different Gellish databases can be merged and integrated whenever required without a need for a conversion exercise. [[br]]
-Furthermore the content of a Gellish Database uses a common Gellish Dictionary for all its data, including for example, equipment types, property types, document types, activity types, etc.
-==== 3.1 Gellish Expressions in a Gellish Database ====
-A Gellish Database is a database that contains one or more standardised Gellish Database tables. Each such table contains the same predefined columns and is suitable for the expression of virtually any kind of fact such that is computer interpretable and system independent. The table can be implemented as an MSAccess database table, an SQL database table or simply as a standard table in a spreadsheet. The core of a Gellish Database table consists of three columns, just as is the case in RDF/Notation 3. Each row with those three columns in such a table expresses a main (binary) fact. For example, the fact that the Eiffel tower is located in Paris can be expressed as follows:
-|**Left hand object**|**Relation type**|**Right hand object**|
-|The Eiffel tower|is located in|Paris|
-|The Eiffel tower|is classified as a|tower|
-|Paris|is classified as a|city|
-The left hand objects and the right hand objects may either be selected from the Gellish English dictionary or may be new proprietary objects that are introduced by defining them on separate lines. If such a new object is an individual thing, then it shall be defined by a classification relation with a class, as is done in the above table and if the nwe object is a class, then it shall be defined on a separate line by a specialisation relation with their direct supertype. The relation types (such as 'is located in' and 'is classified as a') shall be selected from the Gellish English dictionary, otherwise the expression cannot be called standard Gellish, but becomes a proprietary extension of Gellish English.
-==== 3.2 Multi-language support ====
-Furthermore, a Gellish database structure supports the simultaneous use of multiple languages. This is enabled because a Gellish database table contains a separate column for the language in which a fact is expressed (see the example table below). Thus a Gellish database supports the use of various natural language specific versions of Gellish. In principle, there is a Gellish variant language for each natural language, depending on the availability of a translation of the Gellish concepts. For example, the Gellish English Dictionary defines Gellish English, and contains partial translations to Gellish Deutsch (German) and Gellish Nederlands (Dutch). International terminology (such as most units of measure and mathematical concepts) is included as International Gellish.
-==== 3.3 Unique identifiers, homonyms, synonyms and automatic translation ====
-A Gellish database uses a unique identifier for each thing, irrespective whether it is a user object, a concept from the Gellish dictionary, a fact or a relation type. The following Gellish database table is an extended version of the above example and includes the language in which the fact is expressed as well as the identifiers of the objects.
-|**Language**|**UID of left hand objet**|**Name of left hand object**|**UID of fact**|**UID of relation type**|**Name of relation type**|**UID of right hand object**|**Name of right hand object**|
-|English|1|The Eiffel tower|101|5138|is located in|2700887|Paris|
-|English|1|The Eiffel tower|102|1225|is classified as a|40903|tower|
-|Dutch|1|De Eiffel toren|103|4691|is a translation of|1|The Eiffel tower|
-The unique identifiers enable the use of synonyms and homonyms and enable that a computer can automatically translate a Gellish expression in a certain language into a Gellish expression in another language. This is caused by the fact that the meaning of a Gellish expression is captured as a relation between the unique identifiers, so that the meaning is language independent. \\
-This adds automatic translation capabilities to Gellish expressions, because a Gellish message can be created e.g. in Gellish English whereas computer software can present it in another Gellish variant, such as Gellish Dutch if a dictionary or a translation is available, such as on the third line in the above table.
-==== 3.4 Auxiliary facts ====
-A full Gellish database table has a number of additional columns that enable the expression of auxiliary facts or data about the main facts. For example, columns for:
-  * a textual definition of the left hand object
-  * the context in which a fact is valid
-  * a unit of measure with its UID
-  * the status of the fact (accepted, proposed, deleted, replaced, etc.)
-  * the originator of the fact
-  * the date of creation of the fact
-  * etc.
-====== 4. Gellish Database Table Definition ======
-The document '[[http://sourceforge.net/project/showfiles.php?group_id=28353|The Gellish Database Definition]]' defines the full set of columns in each table of a Gellish Database. It also defines a number of standardised subsets for usage in applications that do not require the full number of columns. \\
-One of those subsets, the Business Model subset, is suitable for nearly all database contents data exchange usecases that describe knowledge and propositions. It application range includes business communication about both designs (imaginary objects) as well as real world objects (observed individual objects) during their lifecycle and about enquiries, answers, orders, confirmations, etc. This table is a superset (indicated in **bold**) of the product model table, so it can also be used for knowledge about classes of objects. \\
-This subset consists of the following columns in the indicated sequence: \\
-, 54, 71, 16, '''39''', 2, 44, 101, '''43''', '''19''', '''18''', 1, 60, 3, '''42''', 15, 45, 201, 65, 4, 66, 7, 14, 8, 67, 9, 10, 12, 13, 50, 68.
-==== 4.1 The Gellish database table header definition ====
-Each Gellish database table file has in principle a table header as illustrated in Figure 3, extended with additional columns as described in this chapter. \\
+    * When data was not covered during the database design and thus is not included in the data model, then such data cannot be stored in the database nor exchanged via such a data file structure.
-A Gellish database table can consist either of a complete set of columns or of one of the pre-defined subsets of columns as described above. \\
+    * Different databases have different data structures, which causes that data in one database cannot be integrated with data from other databases nor exchanged between databases without dedicated data conversion.
-Each column has a column ID and a column name and has a meaning as defined below. \\
+    * A database modification or extension requires redesign of the database structure, modification of software and data conversion, which makes such modifications a relatively complicated and costly exercise.
-Note that the presence of a value in a column field implies one or more relations with values in other columns as described below. //Those relations define the facts about the objects!//
-If the table is implemented in a spreadsheet or ASCII or Unicode file, then the table starts with a header of three lines, as follows:
-  * The first line contains a sequence of the following four fields A1, A2, A3 and A4, which shall contain the following text:
-A1 = ’Gellish’ \\
-A2 = ‘Version:’ \\
-A3 = version number of the applicable Gellish dictionary \\
-A4 = date of the release of the facts in this table (optional). \\
-followed by free text fields.
-  * The second line contains the column ID’s which consists of standard numbers, although arbitrarily chosen. They allow the columns to be presented in a different sequence without loss of meaning (the numbers below correspond to those column ID’s).
-  * The third line contains human readable text in every column field providing a short name of the column. This name is free text.
-  *
-==== 4.2 The Gellish database table body column definitions ====
-The lines in a Gellish database table are independent of each other and thus the lines may be sorted in any sequence, without loss of semantics (meaning).
-Each line (row) in the body of a Gellish database table (which in a spreadsheet starts on the fourth line) expresses a group of facts, which consists of a ''main fact'' and a number of ''auxiliary facts''.
+Another characteristic of conventional databases is that there are hardy international standards available or used for the //content //    of the databases, being the data that is entered by its users. This typically means that local conventions are applied in order to limit the diversity of data that may be entered in those databases. As local conventions usually differ from other local conventions this has as disadvantage that data that are entered in one database cannot be compared or integrated with data in other databases, even if those database structures are the same and even if the application domain of the databases is the same. For example, within a company there may be various implementations of the same system in various sites for the storage of data about equipment, whereas for example the performance data about the same type of equipment in different systems still cannot be compared with the performance data in other locations, because the equipment types have different names and the properties are also different.
-**Main fact.** \\
-A main fact is expressed by a combination of the following three objects in the columns:
-  * A left hand object id (2), a fact id (1) and a right hand object id (15).
-**Prime auxiliary facts.**
+====== 3. Characteristics of Gellish enabled databases ======
-The prime auxiliary facts are expressed by the following pairs of objects (the third object that identifies the fact is left implicit, but should be made explicit in a database):
-  * The relation between the left hand object id (2) and the left hand object name (101).
+A Gellish database does not have the semantic limitations that conventional databases have, because of the flexibility and openness of the Gellish language and because of its standard universal data structure (syntax), which is simple and computer as well as human interpretable. \\  A Gellish database consists of a representation of the content of one or more tables in the Gellish Expression Format. For example, the Gellish Communicator software system includes an object-oriented database that is implemented in the form of a network of binary relations 'objects' (in which an 'object' may be anything), whereas each object definition includes all the Gellish Expressions that are applicable for that object. The fact that those Gellish Expression Tables are standardized and universally applicable makes a Gellish database application independent. \\
-  * The relation between the right hand object id (15) and the right hand object name (201).
-  * The relation between the fact id (1) and the relation type id (60).
-  * The relation between the relation type id (60) and its name (3).
-**Secondary auxiliary facts.**
+The Gellish enabled database is universally applicable because it enables the application of the following fundamental principles:
-The secondary auxiliary facts are expressed by the pairs of objects that form the context for the validity of the id’s and names for objects identified by their id’s:
+    - Explicit classification and specialization relations.\\  Explicit classification of individual things or explicit specialization of kinds of things (concepts, classes and types), with an unlimited number of kinds of things in a taxonomic dictionary.
+    - Unlimited extendability, formal and open.\\  Gellish enables storing any kind of statement about any kind of thing; because any individual thing can be introduced by specifying an explicit classification relation between the individual thing and a kind, whereas kinds can be selected from an unlimited open dictionary. The dictionary consists of a core of generic concepts. This core can be used in combination with the large Gellish Taxonomic Dictionary (or a subset of that) and can be combined with a proprietary or public extensions and translations.  This flexibility is fundamentally different from conventional databases that predefine the object types (classes) about which information can be stored by defining a limited number of entity types and attribute types in a fixed data model.
+    - Unlimited semantic expression capability.\\  The semantic expression capability is provided by explicit classification of relations (expressions of ideas) by an extensible unlimited number of standardized relation types.
+    - Powerful standard Gellish set of contextual facts.\\  Gellish enables storing any kind of idea about any kind of object, because any idea can be expressed by one or more binary relations, whereas those relations are explicitly classified by relation types that can be selected from the standardized collection of relation types that are defined in the Gellish Taxonomic Dictionary or by relation types that are added to the dictionary as proprietary extensions. This flexibility is also fundamentally different from conventional databases that predefine a fixed and limited number of kinds of relations between the columns in the database tables (whereas unfortunately those kinds of relations are usually defined only in an implicit way).
-  * The relation between the main fact (1) and its validity context (18).
-  * The relation between the left hand object id (2) and its uniqueness context (17).
-  * The relation between the right hand object id (15) and its uniqueness context (52).
-  * The relation between the uniqueness context for the left hand name (16) and the relation between left hand object id and left hand object name (2, 101).
-  * The relation between the uniqueness context for the right hand name (55) and the relation between right hand object id and right hand object name (15, 201).
-**Ternary auxiliary facts.**
+As a consequence, Gellish enabled databases do not need to be modified or extended when the scope of an application changes. And expressions from different Gellish enabled databases can be merged and integrated whenever required, without a need for a conversion exercise. Furthermore the content of Gellish enabled databases is standardized by using a common Taxonomic Dictionary for all its data, including for example, kinds of equipment, kinds of properties, kinds of documents, kinds of activities, etc., etc.
-Some ternary auxiliary facts as described in the table below.
-Dependent on the type of main fact (the main relation and its relation type) slightly different auxiliary facts can be distinguished and thus slightly different conventions are used to fill in the fields on the line as indicated in the table below.
+//Continue with //     [[:dictionary_extension|1. Domain Dictionaries and Dictionary Extensions]]
-Several columns contain unique identifiers (UID’s). Each UID should preferably be represented by a 64-bit integer (8-byte, Int64 or bigint'''),''' whereas only positive values shall be used. It is not recommended to use an unsigned integer (which only allows positive values) because SQL only enables the bigint datatype, which is signed. \\
-Most other columns contain character ''string values''. For database implementations it is indicated whether they have a fixed or variable length (''nvarchar'' of ''varchar'') or whether the string is externally stored (data types ''ntext'' and ''text''). In addition to that it is indicated whether the cells may contain Unicode. \\
-Fields in columns that are indicated as optional may be left empty, in which case the indicated default value is applicable. Otherwise a field value is obligatory.
-The table columns in a Gellish database table are defined as follows (the Col id numbers correspond with the column ID’s in a table):
+[1]See [[http://support.microsoft.com/kb/q180162/|http://support.microsoft.com/kb/q180162/]]
-|**Col id**|**Column name (name in database)**|**Data type, Optionality, Default, Description**|
-|0|Presentation key (Sequence)|string (optional), default null. A presentation key indicates a position or field in a presentation structure, such as a spreadsheet or a list of lines. It can support //sorting// the content of a Gellish database table. It has no contribution to the meaning of the facts represented on the line. The presentation key does not effect the meaning of the lines. This column can be arbitrarily filled-in for use in a specific context.|
-|69|Unique language identifier (LanguageUID)|integer (optional), 64 bit, default null. The unique identifier of the language in which the name of the left hand object (see column 101) and the name of the relation type (see column 3) is spelled and, if present, in which the definition (see column 63 and 4) is spelled. The language is a context for the origin of the referencing relation between the UID and the string that is the name.|
-|54|Name of language of left hand object name (Language)|string (optional), Unicode, nvarchar(255), default null. The name of the language of the left hand object name indicates the name of the language for which a UID is given in column 69 and that is a context for the name of the left hand object (see column 101) and the name of the relation type (see column 3). If the relation type name is not available in that language, it may be given in English. The allowed values for ‘language name’ are the names defined in the Gellish Dictionary (or your private extension). Currently the dictionary contains names of natural languages and of (artificial) programming languages. For example: - natural language is a conceptualization of English, French (francais), German (Deutsch), etc. The language ‘International’ shall be used to indicate strings that are language independent.|
-|17|Uniqueness context for left hand object id. (ContextLHUID)|string (optional), Unicode, nvarchar(255), default ‘Gellish’. The uniqueness context for left hand object id provides the context within which the left hand object id, given in column 2, is a unique reference to something. The default context is 'Gellish'. This column is //**superfluous**// in normal Gellish, because each object has a Gellish UID and an id in another context can be specified as a name (or synonym) of the object with the Gellish UID. The column is intended for research in the field of multi-language, multi-context integration.|
-|2|Unique left hand object identifier (UID-2) (LHObjectUID)|integer, 64 bit. A unique left hand object identifier is the identifier of the main object about which the line defines a fact. That main fact is an association between two objects mentioned in column 2 and 15. The external identifier (name) of the object in column 2 can be given in column 56 with its text attribute in column 101 ‘name of left hand object’. A '''UID''' is an artificial sequence number, provided it is unique in a managed context. For example, the UID 4724 is a reference number of a telephone extension in the context of my company in The Hague. An identical number may refer to a different object in a different context, such as the extension with UID 4724 in the context of your company. The uniqueness context is given in column 16 (subject area). Such a context itself is defined on a separate line in a Gellish database table. Note, that a fact represented by an association or relationship is also an object.|
-|71|Uniqueness context identifier for left hand object name (UID-7) (LHContextUID)|integer (optional), 64 bit, default null. The uniqueness context identifier for left hand object name, also called the identifier of the language community, provides the context within which the left hand object name in column 101 is a unique reference to the object id in column 2, in addition to the language context (see column 69 and 54). The context is superfluous (and is for human clarification only) on all lines other than lines with a specialization, a qualification a classification or an alias relation and their subtypes, because only there the left hand objects, identified by their UID, are ''defined'' to have a name. If no context is given on a definition line, then the name for the left hand object is unique in the whole (natural) language (column 54) and no homonyms are then allowed (in the Gellish Dictionary).|
-|16|Uniqueness context name for left hand object name (language community) (LHContextName)|string (optional), Unicode, nvarchar(255), default null. The uniqueness context name for left hand object name is the name for the uniqueness context of which the identifier is given in column 71. The name is optional (and is for human clarification only) because the context UID in column 71 shall be a reference to a context that is defined on another line, where its UID and name appears in columns 2 and 101 respectivily.|
-|38|Left hand object type name (LHObjectType)|string (optional), Unicode, nvarchar(255), default null. An object type of the left hand object (with the UID in column 2) indicates the name of the entity type of the left hand object in a particular data model about which the line defines the main fact. This column is superfluous in Gellish as it can be inferred via inheritance from the mapping of the appropriate object or its classifying class in the Gellish specialization hierarchy to the entity in appropriate data model.|
-|39|Reality (LHReality)|string (optional), Unicode, nvarchar(255), default null. The reality is a classification of the left hand object, being either //imaginary// or //materialized// (= real). This indicates that the object is either a product of the mind or an object whose existence is based in the physical world, either as natural or as artificial object. If not specified, then the reality shall be interpreted from the context or from a explicit classification fact. For example, during design a pump will be an imaginary (although realistic) object, when fabricated a pump will be a materialized object. Note that an object cannot be imaginary and materialized. An installation relation relates an imaginary object to a materialized object. Classes are always imaginary.|
-|56|Identifier of left hand term (UID-6) (LHTermUID)|integer (optional), 64 bit, default null. The identifier of left hand term is the unique identifier **of the name** in column 101, which is a name of the object identified in column 2. It is the UID of the encoded information to which the text in column 101 refers and vice versa. Basically this column is superfluous and is therefore left blank, because each unique string in column 101 identifies itself as a unique string. Therefore the string itself is its own unique identifier.|
-|44|Left hand object cardinalities (LHCardinalities)|string (optional), non-unicode, varchar(32), default null. For common associations between classes this column contains the **simultaneous cardinalities for the left hand object class**. This means that it indicates the minimum and maximum number of members of the class that can be associated with a member of the right hand object class at the same time. The cardinalities may be specified by: - a comma separated list of two integers that indicate the lower and upper limit cardinalities. The upper limit may be the character ‘n’ to indicate that the upper limit is unlimited.|
-|101|Left hand object name (LHObjectName)|string, Unicode, nvarchar(255). A ‘name’ of the object identified in column 2 and associated with it via an “is referenced as” association in a context referred to in column 54. For example, a tag name or some other code. It is the attribute of the encoded information identified in column 56. When there is no ID filled-in in column 56, then the text is only present for easy human reference to an object. It facilitates readability when the lines are sorted in a different sequence later. Nameless objects can exist, which implies that there is no instance in column 56 and 101 for an object in column 2.|
-|72|Identifier of left hand role (LHRoleUID)|integer (optional), 64 bit, default null. An identifier of left hand role identifies the role that is played by the left hand object in column 2. This role is implicitly classified or is implicitly a subtype of the first or second kind of role that is required by the kind of relation in column 60.|
-|73|Name of left hand role (LHRoleName)|string (optional), Unicode, nvarchar(255), default null. A name of left hand role is the name of the role in column 72.|
-|43|Intention (Intention)|string (optional), non-unicode, varchar(255), default ‘true’. An intention indicates the extent to which the main fact is the case or is the case according to the author of a proposition. An intention includes also a level of truth. If a line expresses a proposition or communication fact, then the intention qualifies the proposition. If a line expresses a fact, then the intention indicates whether the relation of the type is **true** or **false (not)** or **questionable (maybe)**. For example, the intention may indicate that a proposition is an affirmative **request** (**question**), **confirmation**, **promise**, **declination**, **statement, denial, probability** or **acceptance**. Default = ‘**true**’, which means a qualification of the statement: this fact “is the case”.|
-|19|Unique identifier of validity context for main fact (ValContextUID)|integer (optional), 64 bit, default null. The unique identifier of validity context for main fact identifies the context within which the fact id, given in column 1, represents a valid fact. If not given, the fact is valid in all contexts.|
-|18|Validity context name (!ValContextName)|string (optional), Unicode, nvarchar(255), default null. The validity context name provides a name of the context that is identified in column 19.|
-|1|Unique identifier of main fact (UID-1) (FactUID)|integer, 64 bit. A unique main fact identifier is an identifier of the //main// fact that is represented on the line (such as an association or possession relationship). This main fact is of the type as indicated in column 3 ‘relation type name’.|
-|60|Relation type ID (RelTypeUID)|integer, 64 bit. A relation type ID is unique ID for the class that qualifies the fact in column 1, whereas a name of the type of relation is given in Gellish in column 3.|
-|3|Relation type name (Gellish) (!RelTypeName)|string, Unicode, nvarchar(255). A //relation type name// (or //fact type name//) is a name of one of the subtypes of relation or class of relation expressed in Gellish English.|
-|74|Identifier of right hand role (RHRoleUID)|integer (optional), 64 bit, default null. An identifier of right hand role identifies the role that is played by the right hand object in column 15. This role is implicitly classified or is implicitly a subtype of the first or second kind of role that is required by the kind of relation in column 60.|
-|75|Name of right hand role (RHRoleName)|string (optional), Unicode, nvarchar(255), default null. A name of right hand role is the name of the role in column 74.|
-|52|Context name for right hand object id (RHUniqueContext)|string (optional), Unicode, nvarchar(255), default ‘Gellish’. A context name for right hand object id is a name that indicates where the object referenced by a UID in column 15 is defined. This column is //superfluous// in normal Gellish, because each object has a Gellish UID whereas an id in another context can be specified as a name (or synonym name, code or identifier) of the object with the Gellish UID. The column is intended for research in the field of integration of data from different sources in a multi-language, multi-context environment. The context name can be an external source. For example, a company database system, an XML namespace, an identifier of a template, or ‘**interface**’ which indicates that the right hand object id is a dummy object identifier, that needs to be replaced by (matched with) an id of another object by an application.|
-|15|Right hand unique object identifier (UID-3) (RHObjectUID)|integer, 64 bit. A right hand unique object identifier is the UID of the object associated with the object in column 2. The name of this right hand object can (optionally) be given as right hand term in column 201. The name of an object that has a name is defined only on a line where the fact type indicates a referencing association to the object. On other lines a filled in name is only meant to support human readability. For dates in column 15/201 there is a Gellish convention that the UID for dates between the year 1500 and 3000 is an integer number that is a concatenation of four digits for the year, two for the month and two for the day, whereas two zero's are used for the month when a whole year is meant and two zero’s for the day when a whole month is meant. For example, January 2006 has UID 20060100.|
-|45|Right hand object cardinalities (RHCardinalities)|string (optional), non-unicode, varchar(32), default null. For common associations between classes this column contains the ''simultaneous cardinalities for the right hand object class''. This means that it indicates the minimum and maximum number of members of the class that can be associated with a member of the left hand object class at the same time. The cardinalities may be specified in the same way as for the left hand object.|
-|55|Uniqueness context for right hand object name (RHUnContextName)|string (optional), Unicode, nvarchar(255), default null. A uniqueness context for right hand object name is a context within which the right hand object name in column 201 for the object with the right hand object id in column 15 forms a unique reference to the object in column 2. N.B. This column is superfluous in ordinary Gellish. It is only applicable when the association type in column 3 indicates a referencing association (‘is referenced as’) or a naming association (‘has as name’) when that reference or name is only valid in the context of this uniqueness context. Typically this context points to a library or language that contains the same object, but with a different name for the left hand object.|
-|42|Description of main fact (template text) (!FactDescription)|string (optional), Unicode, nvarchar(255), default null. A description of the main fact (column 1) is meant to be presented to a user. The text is intended as an aid for interpretation of the meaning of the main fact in its context and may imply an instruction to a user for what should be filled in as a value for the right hand term or what should be selected from a pick list in order to finalise a fact or group of facts. The text might appear on a user interface (e.g. a fill-in-the-blanks form or data sheet) and supports human understanding of the meaning of the fact(s) and the intention of the object in column 15 and 201 and optionally the UoM in column 7. For example: the text 'temperature of the fluid at inlet' suggests that a value and a unit of measure should be supplied.|
-|201|Right hand object name (RHObjectName)|string, Unicode, nvarchhar(255). A right hand object name is a string or value which is a textual name of the object identified in column 15, and which is associated with the object in column 2 with a name in column 101. For example, a tag name or code, numeric value, class name or free text description.|
-|65|Partial description (!PartialDefinition)|string (optional), Unicode, ntetxt, default null. A partial description is a description that together with the relation type name (column 3) and the right hand object name (column 201) forms a full definition as presented in column 4.|
-|4|Full definition (!FullDefinition)|string (optional), Unicode, ntetxt, default null. A full definition is a textual description of the characteristics that identify the left hand object or members of the left hand object class. Typically this is a concatenation of the term “is a(n)”, the right hand object name and the text in column 63 (partial description).|
-|66|Unit of measure identifier (UoMUID)|integer (optional), 64 bit, default null. The unit of measure identifier identifies the scale used for interpretation of the numeric value of a property in column 201. In case column 201 contains a concept of property name, the indicated UoM UID in column 66 indicates the default.|
-|7|Unit of measure name (UoM) (UoMName)|string (optional), Unicode, nvarchar(32), default null. The unit of measure name is the name of the scale used for interpretation of the numeric value of a property in column 201. In case column 201 contains a concept of property name, the indicated UoM in column 7 is a name of the default.|
-|76|Accuracy of mapping UID (AccuracyUID)|integer (optional), 64 bit, default null. The identifier of an accuracy of a quantification mapping identifies a numeric range that is defined by two tolerances. The tolerances are defined relative to a common pivot value. The range defines the accuracy of the quantification mapping relation between a property and a numeric value on a scale, where the numeric value has a role as pivot value. For example, a range that is defined from –0.3 to +0.4 can be used to indicate the accuracy of a diameter. When the diameter maps on scale as equal to 5 mm with an accuracy that range around the pivot value (5), then this means that the diameter is between 4.7 mm and 5.4 mm.|
-|77|Accuracy of mapping name (!AccuracyName)|string (optional), Unicode, nvarchar(255), default null. The accuracy of mapping name is a name for the concept in column 76. For example: ‘accuracy of –0.3 and +0.4’.|
-|70|Picklist UID (DomainUID)|interger (optional), 64 bit, default null. The unique identifier for the collection of objects from which values for instances of the right hand term may be selected in the context of an instance of the left hand term. Note, this column (together with column 20) is meant as a short-cut for subtyping a (right hand) aspect type in the context of the left hand object and adding an additional line which defines that the value for a subtype “shall be one of the” picklist collection of aspect values. For example, model X shall have a colour from the list of “model X colours” is a short cut for: model X shall have a model X colour model X colour is a specialization of colour and model X colour shall be one of the model X colours.|
-|20|Picklist name (!DomainName)|string (optional), Unicode, nvarchar(255), default null. The name of a picklist or domain identified by the Picklist UID in column 70. The name of the picklist shall be unique in the same context as the context for the right hand term (column 201) as defined in column 16 on the line where the right hand term is defined and occurs as a left hand term.|
-|14| Remarks (Remarks) |string (optional), Unicode, ntext, default null. A remarks field is intended for comments related to the fact or the existence of the left hand object, its definition or status. The remark is implicitly associated with the fact via: association …“is described by” //remark//. Formally this is encoded information, classified as “remark”.|
-|8|Approval status of main fact (!ApprovalStatus)|string, non-unicode, varchar(64). An approval status indicates the status of the main fact. The status of the other facts on a line can be derived from the status of the main fact. A status can be any of the qualifications of ‘approval status’ in STEPlib. For example: proposed, issue, deleted, proposed to be deleted, ignore, agreed, accepted, accepted association (= only the main fact is accepted), or replaced (see also the “Guide on STEPlib). The status ‘replaced’ indicates that the main fact is deleted and that a successing fact (see column 64) exists. The reason of the status may be clarified in the remarks column (see column 14).|
-|67|UID of successing fact (SuccessorUID)|integer (optional), 64 bit, default null. The UID of the fact by which this line, and especially the main fact which UID is given in column 1, is replaced when the status in column 8 is "replaced". It indicates that there exists a succession relation between the two facts. Note: If the relation type is the last classification relation or specialization relation for the left hand object, then the life of the left hand object is terminated and replaced by the left hand object of the successing relation.|
-|9|Date of start of validity (!EffectiveFrom)|date/time, stored as a real value in the ‘1900 date system’**[1]**. A date of start of life is the moment of the begin of the validity of the main fact. It is implicitly associated with the main fact via a “valid since” relation. The ‘1900 date system’ enables very accurate timestamps, for example for the recording of moments of measurement.|
-|10|Date of latest change (end of validity) (!LatestUpdate)|date/time, stored as a real value in the ‘1900 date system’. A date of latest change indicates the latest change of one of the auxiliary facts. If the status in column 8 is “deleted”, “replaced” or “history”, then the data of latest change indicates the moment of the end of the validity of the main fact. Then it is assumed to be related to the main fact by a “valid until” relation.|
-|12|Author of latest change (Author)|string (optional), Unicode, nvarchar(64), default null. The person who is the originator of the proposition or of the expression of the fact and who has (limited) responsibility for the content of the line; especially its latest change. It is good practice to provide this information, although strictly speaking it is optional.|
-|13|Reference or Source (Reference)|string (optional), Unicode, nvarchar(255), default null. One or more organisations, persons or positions in organisations or (parts of) documents that act as the source or point of reference for the main fact. It is good practice to provide this information, although strictly speaking it is optional. It may include URI strings.|
-|53|Line identifier (UID-5) (LineUID)|integer (optional), 64 bit, default null. A line id (UID-5) is the identifier for a single row in a Gellish database table. It indicates the collection of facts (or ‘cloud’ of related things) in which the main fact and the auxiliary facts on one single line in a Gellish database table are included. It may be used to distinguish different expressions of the same fact (with the same fact UID (see column 1). For example, to distinguish the same fact expressed in different languages.|
-|50|Unique plural fact identifier (UID-4) - see figure 3. (CollectionUID)|integer (optional), 64 bit, default null. A unique plural fact id is a unique //identifier// of a //collection of facts// in which the fact as identified in column 1 is included. This column is intended to indicate a collection of which the elements are facts that are identified by the above mentioned unique main fact identifiers (UID-1). A plural fact identifier is typically used as an //identifier// of a //model// or //(sub) template// or //view//. When a plural fact identifier is filled-in, it implies the existence of an inclusion relation (.. is an element of ..) between the main fact on this line identified in column number 1 and the collection of facts identified in column number 50. The name of the collection may be given in column 68. Collections may appear as left hand or right hand objects in main facts, for example in the definition of larger collections.|
-|68| Name of collection of facts (!CollectionName)|string (optional), Unicode, nvarchar(255), default null. The name of collection of facts indicates the collection of main facts in a Gellish database table, which collection is identified by the UID in column 50. The facts in the collection might be managed together. The main fact on the line is an element of the collection. The collection may indicate for example an area of responsibility of a peer group, the content of a table or the facts on a data sheet.|
-|80|Left hand string commonality (LHCommonality)|string (optional), non-unicode, nvarchar(64), default null. A left hand string commonality specifies for a query in which way a search string has or shall have commonality with a target string that is a left hand object name. A string commonality may have one of the allowed values that are specified as qualifications of a string commonality in the Gellish Dictionary. For example: * case insensitive identical * case sensitive partially identical * case insensitive partially identical * case sensitive front end identical * case insensitive front end identical * case sensitive different * case insensitive different * equal * unequal * less than or equal * great than or equal. The default in a query is ‘case sensitive partially identical’|
-|81|Right hand string commonality (RHCommonality)|string (optional), non-unicode, nvarchar(64), default null. A right hand string commonality specifies for a query in which way a search string has or shall have commonality with a target string that is a right hand object name.|
-//Continue with //[[:Dictionary Extension]] \\
+\\
-[1]See [[http://support.microsoft.com/kb/q180162/]]

Gellish Wiki

User Tools

Site Tools

Differences

Page Tools