- 1. Gellish
- 2. Overview of this Wiki content
- 3. Information Management
- 4. The Gellish Modeling Method
- 5. What is Gellish
- 6. Gellish English
- 7. Usage of Gellish
- 8. Gellish Databases and Messages
- 9. Gellish Domain Dictionaries
- 10. Gellish in XML and RDF / Notation 3
- 11. Development and maintenance of Gellish
- 12. Gellish Documentation
The Gellish project on SourceForge has as purpose to enhance the Gellish Modeling Method for the semantic modeling of knowledge and information and the Open Source Gellish English language with its smart Gellish English Dictionary (earlier called STEPlib) and other variants of Gellish in various natural languages, such as Gellish Nederlands. The related Gellish Information Management Method is based on this modeling method and language. The project also aims to develop documentation and guidance on how to create Facility Information Models (FIMs), Building Information Models (BIMs), Product Models, etc, as well as Domain Dictionaries, Object Libraries, Knowledge libraries and Requirements models, all as applications of the Gellish language. The project also develops guidelines for the creation and use of (certified) Gellish enabled software tools and Gellish databases, the integration of data from different sources and the exchange of Gellish messages between systems in a neutral and system independent way. Furthermore the project describes how Gellish databases can be automatically translated by Gellish enabled software from one natural language to another so that facts that are expressed in one language, for example English, can be Travel and Leisure: Hotels Accommodations to users in other languages, such as Dutch, Russian, Chinese, Japanese, Arabian language, German, etc.
Additional information, licenses and support services are avialable via the Gellish.net website
2. Overview of this Wiki content
Those who want to study Gellish in a systematic way are recommended to study the wiki pages in the sequence below:
1. Home (this page: Introduction in Gellish)
2. Basic principles
3. Gellish Modeling Method
4. Gellish English Dictionary (Gellish Dictionary)
5. Facility Information Models (FIM), Building Information Models (BIM), etc.
6. Product Modeling (Product Design)
7. Modeling of activities and processes
8. Document Management
9. Knowledge modeling in Gellish
10. Requirements Models
11. Standard Specification Models
12. Correct Gellish English
13. Data Modeling and Database Design in Gellish
14. Development of Gellish enabled software
15. Gellish Database (Gellish Table)
16. Dictionary Extension (Proper definition of a concept)
17. Rules for names of concepts
18. Gellish messages
19. Querying a Gellish English database
20. Gellish Semantic Web
21. Verification of designs
22. Automatic translation
23. Information Management process
24. Change Management
Appendices: Alphabetic lists of relation types
The expression power of Gellish is largely determined by the more than 650 standard relation types that are listed in the following appendices and that are defined in the upper ontology section (TOPini) of the Gellish English Dictionary (see: Download area). The TOPini definition table can be directly imported in Gellish enabled software to enable computer interpretation of Gellish expressions.
The appendices show that each relation type is identified by a unique identifier (Gellish UID). Furthermore, each relation type is denoted by a Gellish phrase and by an inverse Gellish phrase. For example, a part-whole relation between two individual things is denoted in Gellish English by the phrase <is a part of> or by the inverse phrase <is a whole for>. This means that the same fact can be expressed in either of the two ways. For example, the expression 'A <is a part of> B' has the same meaning as the expression 'B <is a whole for> A'. A relation type can also be denoted by alternative synonym phrases, such as <is part of>, or by phrases in other languages. Users may even define their own synonym phrases (provided that the UID remains the same) and they can indicate a 'language' and/or a 'language community' in which their phrase is preferred. For example: Nederlands (Dutch) <is een deel van>.
This Wiki has a limit on the maximum size of a page. Therefore the list of relation types is presented in several parts with preferred standard phrases and inverse phrases. At the bottom of each partial list you will find a reference to the next part.
Standard synonym phrases will be added at a later stage.
25. Appendix A - part 1: List of types of relations between individual things
26. Appendix A - part 1A: List of types of relations between individual things (continued)
27. Appendix A - part 2: List of types of relations between an individual thing and a kind of thing
28. Appendix A - part 3: List of types of relations between kinds of things
29. Appendix A - part 3A: List of types of relations between kinds of things (continued)
30. Appendix A - part 3B: List of types of relations between kinds of things (continued 2)
31. Appendix A - part 4: List of types of relations between a single thing and a plurality
For Dutch speaking people: see also Gellish Nederlands
Note that each Wiki page has its own table of content.
3. Information Management
The Gellish Information Management Method is independent of the use of the Gellish Modeling Method and the Gellish language. However, their use strongly supports and simplifies information management, because of their ability to uniquely identify and manage each individual fact and because of their uniformity in storage (and thus for management) of all kinds of facts. The Gellish Information Management Method covers storing and retrieval of data, documents and knowledge as well as information exchange between various parties and systems. The section of this Wiki called Facility Information Models describes the integrated modeling of data and documents about individual objects and the processes that take place in and with those objects. The sections called Document Management and Change Management describe a method for storing information as well as physical document files in a Gellish database, including the storage of relations between documents and the objects about which they provide information. That part also includes a description of the method to model documents and data sets and information about them, usually called meta-data, as well as the references to physical media, such as electronic files or paper versions.
4. The Gellish Modeling Method
The Gellish Modeling Method is a powerful modeling method that uses standard Gellish English for modeling in at least the following five area's:
- The creation of computer interpretable Domain Dictionaries, arranged in the form of a Taxonomy (subtype - supertype hierarchy) and optionally extended with explicitly modelled definitions in the form of Definition Models. Domain Dictionaries are typically created as extensions of the general purpose Gellish English Dictionary.
- The creation of knowledge libraries in the form of collections of Knowledge Models for the expression of knowledge about kinds of things in a computer interpretable form.
- The expression of Requirements and Standard Specifications in the form of Requirements Models for the computer interpretable description of standard products and components and their properties and performance as in product catalogues and in general requirements as expressed in internationational standards and company best practice guides.
- The creation of Facility Information Models that contain data and documents about individual objects, including data and documents about designs of objects as well as about realised facilities and their operation and maintenance.
- The exchange of messages, including queries, answers and statements between Gellish enabled software, for a Gellish Semantic Web.
The Gellish Modeling Method improves conventional data modeling methods in various respects. Conventional data modeling, for example Object-Role Modeling (ORM) or Entity-Relationship (ER) modeling, do not provide a dictionary, nor do they provide standardised relation types to express facts, nor do they provide a standard database design or data structure. As a consequence the various models that result from the application of such methods are implemented as different dedicated databases, so that every supplier created its own database structure. However, such databases are all mutually incompatible, whereas data that is stored in one database can only be transferred to other data stores by the creation of costly conversion and interfacing software. This problem can be solved by using the Gellish Modeling Method that uses the standard Gellish English Dictionary concepts, including its standardised relation types, to create knowledge and information models in a standard universal Gellish Database. When conceptual data models are expressed as knowledge models in Gellish English and when they are stored in a Gellish Database, then they can be used directly to guide the creation of information models about individual objects. Furthermore, that data can also be stored directly in a standard Gellish Database without the need to create a dedicated database. This is enabled by the fact that each Gellish Database consists of one or more of the same universally applicable standard database tables. This general applicability eliminates the need to create dedicated database designs for new applications. As a consequence it is not required anymore to convert the conceptual data models into physical data models to create a database structure. This also opens the possibility to create software that can operate on any Gellish Database or on the combined content of multiple Gellish Databases as well as on any Gellish exchange message.
5. What is Gellish
Gellish is a generally applicable and formal subset of a natural language and a neutral and system independent data structure. Gellish is designed to enable people and computers to express, store, exchange and integrate information and knowledge in and between computers without the need for costly data conversions and interfaces between systems.
5.1 The Gellish language
The Gellish language is primarily defined as a structured subset of English, resulting in Gellish English. However, Gellish is based on the understanding that words and phrases in natural languages are representations of concepts that are language independent. Therefore, each concept in Gellish has a unique language independent identifier (UID) that represents the concept as such. In addition to that, each concept can be denoted by multiple terms ('names'), synonyms and abbreviations in any language. This enables automated translation of expressions between different languages. It means that facts that are expressed in one language do not need to be translated to other languages, as the computer is able to present such a fact in any language for which a Gellish Dictionary is available.
This document primarily describes Gellish English, but for any other language variant you may replace the word English by the name of that other language. So, Gellish English is a subset of natural English, in the same way as the Dutch variant (Gellish Nederlands) is a subset of the Dutch language. Other Gellish variants are in a similar way subsets of other natural languages.
Gellish is intended to facilitate standardisation of data in databases, and to provide a universal data structure for a data exchange and a generally applicable database capability. Its main advantages over conventional information and knowledge modeling methods are:
- Its data structure is universal and flexible and can be extended without software changes or database definition changes, whereas conventional data structures are fixed and inflexible.
- It is an open language in which any semantically correct information or knowledge can be expressed, whereas conventional database structures only allow for data for which the system was designed.
- It has an extensive standard 'smart' dictionary of concepts and relation types in the form of a taxonomy / ontology, which eliminates ambiguity and causes that data from different sources can easily be integrated, whereas conventional databases usually don't use standard concepts for their definition, nor for their content.
- It is open, system independent and free available under Open Source conditions, whereas most data structures and content standards are closed, application software dependent and proprietary.
- It has automated translation capabilities, uses normal English terms and expressions and does not use a separate meta language for its definition, whereas conventional systems need ad hoc translations and require the use of a separate meta language for their definition and are usually expressed in 'programmers language'.
Gellish is based on the principle that knowledge and information can be regarded as a collection of elementary facts, whereas those elementary facts can be expressed as small computer interpretable expressions (small sentences) that are the same in any natural language. Each such elementary expression has the form of an object-relationship-object (ORO) structure. Examples of such Gellish English expressions are the knowledge:
- turbine <can be a part of a> car
and the requirement:
- car <shall have as part a> engine
and the information:
- the Eiffel tower <is located in> Paris
Such Gellish expressions use standard terms for concepts that are selected from the Gellish English Dictionary (or a private or public domain extension or Domain Dictionary) and also use standardised relation types from that dictionary. This standardisation makes Gellish a formal language that enables that Gellish expressions can be directly integrated with other Gellish expressions (without a need for conversion) and that the expressions can be interpreted by computers.
The Gellish language is also capable to express questions, answers, confirmations, denials and other communicative intents. Therefore, Gellish does not need a special query language. Gellish Databases can thus be queried via Gellish Queries. This is further described in the section Querying a Gellish English database.
A Gellish Dictionary defines the concepts and terminology of the language, including also phrases that denote relation types. Each concept and each relation type is defined as a subtype of a more general concept or relation type. This means that the concepts and relation types are defined and arranged in a subtype-supertype hierarchy, also called a Taxonomy. This means that the subtypes inherit the definitions of their supertypes. A consequence of the Taxonomy structure is that Gellish expressions can be automatically verified on their consistency and grammatical correctness.
The hierarchy of relation types is shown in the sheet called 'Gellish English' of the TOPini spreadsheet file of the Gellish English Dictionary. For searching for specific relation types or concepts and for viewing their hierarchy it is recommended to use a Gellish Browser (This Wiki is not suitable to represent that hierarchy, so that the Appendices only present an alphabetic flat list of relation types).
5.2 The standard Gellish data structure
Gellish includes a definition of a standard universal database structure. This means that from an information technology perspective, Gellish can be regarded as a large integrated data model that is flexibile and generally applicable and can be implemented in one or more identical database tables. It is flexible, because its application scope and semantic expression capabilities can be extended without a modification of the Gellish data structure. It is generally applicable, because it has generally applicable standard relation types and embedded domain specific knowledge from various discipline areas, which relation types and knowledge can be easily extended to other domain areas.
This means that Gellish expressions can be stored in universal Gellish Databases and can be exchanged between systems via Gellish messages that use a standardised Gellish interface.
6. Gellish English
6.1 Structured formal English
Gellish English uses terminology from the natural English, nevertheless Gellish may also be called a formal language that is computer interpretable, because it limits the language to a formally defined, and computer interpretable subset of a natural language. However, Gellish English does not define its own vocabulary, but uses the English vocabulary that is defined in the electronic Gellish English Dictionary or in user defined Domain Dictionaries. Thus the Gellish English Dictionary provides standardised terminology that can be used as a 'common language' in application systems. Typically it can be used to enhance conventional databases by standardising their content and thus simplifying data integration and data exchange between systems. For example, the standard terminology and concept definitions can be used for standardising the content of multiple implementations of systems, such as ERP, PLM and EDMS systems, that need to share or exchange data.
6.2 A smart English Dictionary
The smart Gellish English Dictionary is an electronic normal English dictionary that is extended with additional knowledge. All definitions and knowledge in the dictionary is expressed as computer interpretable relationships between the concepts in the dictionary. Most of the relations are specialization relations that specify that the concepts are subtypes of their supertype concepts. This results in a subtype-supertype hierarchy, so that the concepts are arranged in a taxonomy. The other additional relations between concepts provide additional knowledge about the defined concepts and thus make it an ontology. Because the relations are computer interpretable, the Gellish dictionary becomes a ‘smart dictionary’.
The Root Segment of the Gellish English dictionary includes definitions of the standard relation types. The definitions of those relation types and the definition of the related kinds of roles and kinds of role players form an upper ontology or world ontology. That section defines the semantics of the Gellish expressions. The Root Segment contains the generic concepts that are the top concepts that can be further specialised in the various domain ontologies. The Root Segment therefore acts as the integrator of the Domain Dictionaries.
The standard Gellish English Dictionary consists of a root section (or TOPini section) with a number of branch sections, called Domain Dictionaries. Usage of Gellish requires the use of the TOPini root section and may use one or more standard Gellish Domain Dictionaries, or may use proprietary Domain Dictionaries.
Examples of standard Gellish Domain Dictionaries are:
- Units of Measure
- Activities, Events and Processes
- Physical objects of various kinds, such as:
- - Static equipment, civil, process units and piping
- - Electrical and Instrumentation, Control and Valves
- - Rotating equipment, Transport equipment and Solids Handling
- Aspects, Properties, Qualities and Roles
- Materials of constructions, Fluids and Waves
- Documents and Identification, Symbols and Annotation
- Geographic objects, Lifeforms and Organizations
- Mathematics, Geometry and Shapes
Users and Organisations are invited to propose extensions of the Root Segment or the standard Domain Dictionaries and are invited to develop Domain Dictionaries for their own application domain and to propose to certify their Domain Dictionaries as approved proprietary or public Gellish Domain Dictionary.
7. Usage of Gellish
There are basically four kinds of usage of Gellish:
- Usage as a Dictionary
- Usage as a Language e.g. to create dictionaries, to model knowledge, to specify requirements, to describe designs or real world facilities or to manage information.
- Usage as a Data Modeling language
- Usage as a Query language
7.1 Usage as a Dictionary
Gellish English is defined in the electronic Gellish English Dictionary. That dictionary can be used either in stand-alone mode via Gellish Dictionary browser software (such as the Gellish Browser) or by incorporating the dictionary (or a subset of it) as standard reference data in one or more application systems.
Examples of usage of the Gellish English Dictionary are:
- Usage for Data Standardisation and common terminology in order to harmonize data in databases in various systems in a company or in an industry. For example, standardise the classification of equipment and their properties, or to standardise document types e.g. in ERP systems, design systems, maintenance systems or document management system.
- Usage for the standardisation of keywords in document management systems.
- Usage to improve search engines for retrieval of information by using the Gellish dictionary terms and synonyms (with possible private extensions) as the basis for allocation of keywords and for the keyword search, while using the taxonomy (subtype-supertype hierarchy) of kinds of things (classes) in the Gellish Taxonomy to find also information that is classified by subtypes of terms.
Usage of the Gellish English dictionary may include not only usage of names and textual definitions, but possibly also the usage of the subtype-supertype hierarchy relations and possible also the facts that express what is definition true for a defined concept.
Application that use only the dictionary may select from the Gellish Dictionary Database only the lines that define concepts and the lines that define synonym names for those concepts. Those lines can be recognised on the relation types which they use, because those lines contain only relation types that are indicated by the following Gellish phrases:
- is a specialisation of - Such a line defines a concept as being a subtype of another concept and provides a textual definition for the concept.
- is a qualification of - Such a line defines that a qualitative or quantitative aspect <is a qualification of> a conceptual aspect. For example, red <is a qualification of> colour, and ASTM 317 <is a qualification of> stainless steel.
- is a synonym of
- is an abbreviation of
These relation types are also some of the standard relation types that are used to extend the Dictionary with the definition of additional concepts. Guidelines for the extension of the Dictionary are given in the Gellish English Dictionary Extension Manual. A summary of those guidelines is provided in the rules for proper definitions of new concepts and rules for names of concepts.
If you need only a subset of the concepts in the Dictionary then it is nevertheless recommended to import the whole taxonomy, but to mark only those concepts that will be visible to users. This will simplify to upgrade to newer releases of the Gellish English Dictionary and will support the inclusion of private extensions.
7.2 Usage as a Language
Using Gellish as a language to create a Gellish Databases includes the usage to describe any or all of:
- Individual objects, their components, properties and behaviour.
- Designs of facilities or real world structures or to manage information about a facility; typically by creating a Facility Information Model or a Building Information Model (BIM).
- Business processes, transactions and other activities, such as processes that are typically described by graphical methods such as IDEF0 and DEMO.
- Physical or chemical processes, including fluid or solid product streams.
- Definitions of concepts and their relations to other concepts, to create smart Dictionaries, Taxonomies and Ontologies.
- Knowledge by creating Knowledge Models that can be re-used to guide designs or to verify designs.
- Requirements for projects or products or standard specifications of kinds of things, such as included in product catalogues.
Usage of the Gellish English language for the modelling of information and knowledge implies that individual things are classified by concepts from the Gellish Dictionary, and in addition to that it implies that standard relation types are used for making expressions of the kind Object-Relationtype-Object (ORO). This is illustrated in the figure below.
The figure illustrates the architecture of a Facility Information Model and its main sections. The left hand section of the figure illustrates a model of a facility, in this example an LNG plant. The facility is decomposed in components, using part-whole relations. The components have properties and can be related to each other. The components can also be related to processes and activities by relations that indicate the way in which they are involved. Each element in the facility model can also be related to one or more documents in a collection of document models, being the second section of the Facility Information Model. These relations in a Gellish model enable to build powerful search engines or product lifecycle and document management systems (PLM's and EDMS's) that can use the structure of the facility model to find documents about the facility components. Each element of the facility model and each document is also related by a classification relation to a concept (a class) in the Gellish Dictionary that is the section on the right hand side of the figure. These relations enable to use the structure of the smart dictionary to find documents and requirements that are applicable for components that are classified by such a concept. Finally, the third section illustrates the expression of requirements about kinds of things, in the form of relations between concepts in the Gellish dictionary. Note that the classification relations determine which requirements are applicable to which objects in the facility model.
Alltogether the figure illustrates the following ways to use the full Gellish language:
- To express knowledge for its storage, retrieval and for the exchange of knowledge between application systems.
- To express requirements and standard specifications for facilities and products and for the required delivery of data and documents.
- To model facilities and their components and products (product modeling or product design) for the storage, retrieval and exchange of data and documents about them, such as in product catalogues.
- To verify designs or to verify observed real world objects against requirements and specifications.
- To create Facility Information Models or to express business transactions, measured data, or any other information about facilities and their components as an integration of information from various sources in a central or decentralized distributed database.
Depending on these kinds of usage a different subset of standard Gellish relation types is applicable. Those subsets of the available relation types are described in the various parts of the Gellish Modeling Method.
Requirements specifications mainly use relation types that specify relations between kinds of things that specify facts that shall be the case. Such relation types are typically indicated by phrases that start with 'shall be...' or shall have...'. Definitions describe facts that are by definition the case. Therefore, definition models include relation type phrases that begin with 'has by definition...' or 'is by definition...'. For example, in Gellish we can specify that a pump shall have a shaft and shall have a volumetric capacity as follows:
|Name of left hand object||Name of relation type||Name of right hand object|
|pump||shall have as part a||shaft|
|pump||shall have as aspect a||capacity (volume flow rate)|
Product descriptions and operational facilities mainly use relation types that specify relations between individual things and classification relations that specify that an individual thing is related to a kind of thing (a class). These kinds of relation types typically start with 'is a...' or 'has a...', whereas the classification relation is expressed by the phrase 'is classified as a'. For example, the information that P-1001 is a pump that has a capacity of 5 dm3/s is described in Gellish as follows:
|Name of left hand object||Name of relation type||Name of right hand object||UoM|
|P-1001||is classified as a||pump|
|P-1001||has as aspect||capacity of P-1001|
|capacity of P-1001||is classified as a||capacity (volume flow rate)|
|capacity of P-1001||is quantified on scale as||5||dm3/s|
Note that the relation types and the concepts pump, capacity (volume flow rate), 5 and dm3/s are all standard Gellish English concepts that are selected from the dictionary. The other objects, P-1001 and capacity of P-1001 are private objects that are introduced in the Gellish language by their classification relations.
7.3 Usage as Data Modelling language
Using the Gellish English language to specify data models, thus using it as a data modeling language. This will result in Gellish English conceptual data models, being data models that are expressed using the relation types that are standardised in Gellish and that use the concepts that are already defined in the Gellish Dictionary or their proprietary extending where necessary. Data models expressed in Gellish have several advantages, such as that they are documented in a database table, they are extensible and they can be directly used by software to guide the creation of data instances, without the need for the design of a physical data model.
7.4 Usage as a Query language
Using the Gellish language to Query a Gellish Database or to communicate in dialogues about transactions with requests, promises, statements, etc., thus using Gellish English as a query language or as a business communication language.
8. Gellish Databases and Messages
Gellish English Databases enable the storage of virtually any data. They can contain any number of identical database tables. Therefore Gellish Database systems have a universal table structure, which makes them generally applicable and extendable without the need to redefine their data structure (data model). All Gellish databases have as common characteristic that they enable to store any knowledge and information that can be expressed in the Gellish English language. They also have as common characteristic that they have the capability to import and integrate data that are expressed in the form of the content of other Gellish Database tables or the content of Gellish messages.
Gellish messages can be exchanged between computer systems, using a standard data exchange protocol, such as the SOAP protocol. Such a message consists of an envelop, a header and a body. The body is formed by a collection of Gellish expressions, similar to rows in a Gellish Database table. When the SOAP protocol is used, the Gellish message is exchanged in XML format. Such messages can be sent as a query or as a response in peer to peer networks of Gellish enabled applications to query a central database or a decentralized distributed database.
Data integration requires the use of a common language, which includes a common dictionary of concepts and relation types. Therefore it is important that users of Gellish should have the discipline to obey the rules for correct Gellish. You should carefully evaluate whether new concepts, especially relation types, are really needed or that existing concepts are already available in the Gellish Dictionary. If you think that a new concept is really required, then you are strongly recommended to provide feedback and to propose your extensions as enhancements of the Open Source and public domain Gellish Dictionary. This is in line with the conditions of the Open Source License that allows you to download and use the Gellish language definition and dictionary.
9. Gellish Domain Dictionaries
The use of Gellish requires at least the use of the TOPini section, which defines the core of the Gellish language (it 'Upper Ontology') and may include part or all of the other sections of the full Gellish Dictionary, called the Gellish Domain Dictionaries, possibly extended with proprietary defined concepts or Domain Dictionaries.
Parties may wish to develop and use their own (proprietary) Domain Dictionary in Gellish and combine that with the concepts that are defined in the upper ontology of Gellish (the TOPini section), and may use one or more standard Gellish Domain Dictionaries (such as the Units of Measure Domain Dictionary) or nothing at all of the remainder of the Gellish Dictionary.
The Gellish Modeling Method provides guidelines on how to create such Gellish compliant Domain Dictionaries.
The use of proprietary Gellish Domain Dictionaries is convenient and fast, because of the familiarity of its users with their own dictionary. However, the use of proprietary Gellish Domain Dictionaries has two main risks:
- Your Domain Dictionary may overlap or conflict with other Gellish Domain Dictionaries. This means that data integration may still be a problem when you want to communicate with systems that are not familiar with your Domain Dictionary. So you cannot simply integrate data from other parties that use a different Domain Dictionary.
- Your Domain Dictionary may contain concepts that are not subtypes of the concepts in the Gellish Root section (TOPini). This is against one of the basic Gellish rules and causes that the correctness and consistency of the Gellish expressions cannot be verified.
For example, not using the ful Gellish Dictionary means that the power of the Gellish taxonomy is not utilized and thus that the benefits of the inheritance capabilities, searching on subtypes and semantic verification possibilities), the synonyms, the definitions and the distinctions between objects and their roles, the standard units of measure and their conversions, etc. are not used.
To avoid these risks of Gellish Domain Dictionaries it is recommended define synonym relations between your own terminology and equivalent names in the Gellish Dictionary that denote the same concepts. This is especially useful when your domain dictionary or the terminology in one or more of your systems is a subset (or translation) of the standard Gellish English Dictionary.
Synonyms can be defined as part of an ordinary Gellish Database table that is part of your Domain Dictionary. Such a Synonym Table should use your Domain name as 'Language Community' and should contain synonym relation types that relate your names to the names from the standard Gellish Dictionary, whereas your concepts are identified by the UID's of the concepts in the standard Gellish Dictionary. For example:
|Language||Language community||Name of left hand object||Name of relation type||Name of right hand object|
|English||SAP||ME_PUM||is a synonym of||pump|
|English||SAP||P||is an abbreviation of||pump|
|German||SAP||Pumpe||is a translation of||pump|
It is also possible to state that a name in your context <is the same as> the same name in the general context of the standared Gellish Dictionary.
You can then add proprietary subtype concepts where necessary.
Examples of such Synonym Tables are available for the ISO 15926-4 Domain Dictionary terminology. Several companies developed such Gellish Synonym Database tables. For example, Synonym tables were made for terminology in various database implementations, such as equipment types and property types in various SAP implementations for maintenance and inspection. In fact in such cases the Synonym table indicates which subset of the standard Gellish Dictionary is used in the application.
A possible implementation could then even use the full Gellish dictionary/taxonomy at the background, while the software only shows the proprietary synonyms of the subset to the users, together with possible proprietary extensions.
Examples of Gellish Domain Dictionaries are the Civil Engineering Domain Dictionary and the Building and Construction Domain Dictionary (in Dutch and English).
10. Gellish in XML and RDF / Notation 3
In Gellish the expression of each main fact accompanied by a number of auxiliary facts. That is the reason why a Gellish Database table consists of a large number of standard columns, although the expression of a main fact basically only requires 3 columns.
Auxiliary facts are for example, facts about the used language, the context for naming and validity, the status, the originator, the date of creation and modification of a fact, unique identifiers, etc. All those auxiliary facts can be expressed on one row in a Gellish Database or data exchange file or message.
A representation of “Gellish in XML” is defined in an XML Schema at http://www.gellikx.com/2008/ns/1.0/GellishSchema. An XML file with data according to that Schema is recommended to have as file extension GML, whereas GMZ stands for “Gellish in XML zipped”.
Users may wish to ignore some or all of the auxiliary facts in their implementation. For that reason standard subsets of columns are defined as is described in the “The Gellish Database Definition” document (see the Download area of this website). The smallest subset is a triple, which includes a left hand object name, a relation type name and a right hand object name. (In RDF those three components are called subject, property and object). Applications that do not require the implementation of the full set of auxiliary facts can use one of the subsets. Each subset table can be represented in XML or RDF / Notation 3 using a subset of the above XML Schema definition.
11. Development and maintenance of Gellish
Gellish Engish is developed and maintained as an International Industry Standard by this Open Source project, headed by dr. ir. Andries van Renssen at Shell and at the Delft University of Technology, together with a team of domain experts from several international companies. Users of Gellish who want to extent the Gellish Dictionary of concepts and relation types are invited to submit their proposals for additions to the Gellish English dictionary or another language variant.
Gellish is in use for a large variety of applications, including facility design, plant data integration, database content harmonisation, knowledge storage and retrieval, electronic product catalogues, database prototyping and development, etc.
Gellish Engish is a combination and significant extension and at the same time a simplification of the concepts defined in ISO data model standards ISO 10303-221 (AP221) and ISO 15926, especially part 2, 3 and 4 and includes enhanced concept definitions from many other standards. A project is in progress to transform Gellish into an ISO standard, thus becoming ISO 15926-11.
12. Gellish Documentation
For the description of some core concepts of Gellish see the page on basic principles. Extensive guidance is provided in the documentation that is described below and can be provided by organisations that support the use of Gellish and the Gellish Modeling Method. Explanation of the interpretation of Gellish expressions and of the standard Gellish relation types is given on the page Developing Gellish enabled software.
The sourceforge website (Download page) contains a number of documents about Gellish, arranged in three packages:
Package 1: The Gellish English Dictionary - Gellish EN
- The Gellish English Smart Dictionary (earlier called STEPlib). The electronic Gellish Dictionary includes an advanced English Dictionary, that contains explicity relations between the defined concepts. It includes also the Gellish English language definition (its grammar) in a computer interpretable form (the TOPini part). It consists of a number of Gellish Database tables presented in MS Excel files. The tables can be combined in one Gellish Database and imported in any database that is compliant with the Gellish Database definition.
Package 2: Examples
- An example of a Road (in English and in Dutch). - The example is described in two files:
- A document that is intended to provide a first introduction in Gellish, using the example. The document describes some knowledge about a road as well as some information about a particular road.
- An Excel file that contains a Gellish Database table with the knowledge and information about the road as is described in the document. The example also illustrates as follows how Gellish enables automated translation. The English version of the database expresses the knowledge and information in Gellish English and includes a translation of the terms (the names of the concepts) to Dutch. That is sufficient for software to present the knowledge and information in Dutch as well, whereas it is not needed to express the facts in Gellish Dutch again. The inverse is the case for the Gellish Dutch version of the database.
- An example of Lubrication System. This Gellish Database consists of three tables, one with knowledge, one with requirements and one with the design of a part of a particular (individual) lubrication system.
Package 3. Gellish Documentation
- A presentation about Gellish in MS Powerpoint.
- Gellish Database Definition - This document defines the standard Gellish Database table and the meaning of the columns in such a table. Such tables can be implemented as database tables or can be exchanged as a computer interpretable files.
- The Gellish Application Manual - An extensive manual on the application of Gellish with many examples.
- A Guide on the extension of Gellish English - This document provides guidance on how to create your own Domain Dictionary or to extent the Gellish English Dictionary with your private terminology and how to raise proposals for the extension of the official Gellish Dictionary. See also the summary of the rules for a proper definition of a new concept and rules for names of concepts.
- Guidelines on the use of Gellish English for essay writing- This document provides a list of guidelines that provide guidance on the usage of Gellish. It also contains rules to determine whether knowledge or information is expressed in a Gellish compliant way. Those rules form the basis for becoming Gellish certified, which gives the right to use the 'Gellish Powered' logo.
- Guidelines for the creation of product catalogues in Gellish.
- A summary of the PhD thesis of the originator of Gellish, with a description og the fundamentals, the definition, development and application of Gellish as a universal data structure and ontology. See also the book 'Gellish, a Generic Extensible Ontological Language' or its free available pdf version.
Continue with Basic principles