Table of content:
Note that each Wiki page has its own table of content about the details on that page.
Table of content:
Note that each Wiki page has its own table of content about the details on that page.
This is an old revision of the document!
A core concept of Gellish is the idea that any information that is expressed in Gellish forms a semantic network. A semantic network is a network in which the nodes (concepts, things) are linked to each other by relations (relationships), whereas those relations have classification relations with other nodes that represent kinds of relations. Such networks can be about individual things as well as about kinds of things or both. Furthermore, each such a semantic network is thus expressed in the formal language. This implies that by definition it forms an integrated whole with the semantic network that defines the formal language. In other word, the concepts that are used in expressions have explicit relations with concepts that are already defined in the language definition or are reused concepts that were defined earlier in the taxonomic dictionary. This means that any information that is expressed in Gellish forms an extension of virtually one integrated semantic network. Such an integrated network may also include expressions of knowledge and requirements. This enables free navigation through a semantic network in any direction. For example from individual things to knowledge or requirements or definitions about kinds of things and vice versa. It also enables the specification of any sub-network of the total network as being a sub-model expressing some specific information.
An Integrated Information Model is a name for the scope of a semantic network that includes various kinds of information about some subject and always includes at least the language definition network. When such an information model concerns a facility, a product, a building, etc., then the result can be called a Facility Information Model, a Product Information Model, a Building Information Model (BIM), etc.
The Gellish Modeling Methodology aims to increase the quality and accessibility of information (documents and data) about one or more subjects (such as a facility or a collection of products) and at the same time to reduce costs of managing data about the subjects and prossibly about their use. The basic vehicle for that is the development and use of electronic
Integrated Information Models. Such a model typically is a model of one or more individual things that can be either designs of particular objects or may be about real world objects or kinds of things, or both. For example, it can be a design of a complete process plant, a building, a road or a road network, a ship or an airplane (which designs are imaginary individual things that only exist in peoples minds), and it can be an object that is fabricated, constructed and installed, operated and maintained or about components of such things or about kinds of things. It can also be about any combination of them.
This paragraph describes what an Integrated Information Model is and it specifies the procedure to create such a model.
An Integrated Information Model that is created according to the Gellish Modeling Methodology is preferably documented in a system independent way in one or more Gellish enabled databases. This means that various parts of the model can be exported from such a system and can be imported in any system that is able to read and interpret Gellish expressions. That is the reason why these pages don't discuss any particular software system, but only deal with their data and document content.
Important kinds of systems in which Integrated Information Models can be implemented are document oriented systems, such as extended Electronic Document Management Systems (extended EDMS’s), Content Management Systems (CMS systems) or Enterprise Content Management Systems (ECM systems). Another kind of systems in which Integrated Information Models may be implemented are more data oriented systems, such as Product Data Management Systems (PDM systems) and Product Lifecycle Management Systems (PLM systems) or ERP systems, typically extended with 2D drawing and 3D shape representation capabilities.
Traditionally information about a product is recorded in documents, first in paper documents, later in electronic documents. In an Integrated Information Model a core part of the information is expressed as data, which data reflects products or processes and their components and the operation or usage of products and possibly their properties, whereas another part consists of the remaining documents. Each of those documents is then related to the element in the product and process model about which the document contains information. Figure 1, Integrated Information Model Architecture
A Integrated Information Model generally has an Architecture as is presented in Figure 1. Such a model typically consists of three, four or five sections:
1. A Product and process model.
A product and process model consists of data in a network structure, so that it forms a model of one or more products and/or processes, their components and properties and relations to other things. This may reflect the design of a facility or product or it may describe an actually fabricated thing, or both.
The product and process model section of an integrated model includes a composition hierarchy (also called a breakdown structure) of the products or processes (being e.g. a process plant, ship, building, road, or component, etc.) as well as the properties of their components. It may also include the processes that take place in the products, together with the processed materials and the activities on its components.
2. Document Models.
Document Models consist of documents that are related to the product, together with data about the documents. An Integrated Information Model shall include relations between the documents and the elements in the product and process model about which they provide information. A document model includes the repository of documents about the product or process as well as the procedures to operate or use, inspect and maintain products.
3. Requirement Models.
Requirements Models form an optional section that describes requirements about the kinds of things in a product and process model, specified in the form of relations between concepts in the Dictionary (using expressions with <shall have…> or <shall be…> relations). For example: a compressor <shall have as aspect a> capacity.
4. Knowledge Models.
Knowledge Models form another optional section that describes knowledge about the kinds of things in the product and process model, also specified in the form of relations between concepts in the Dictionary. Expressions in such models use different kinds of relations (<can have…> or <can be…> relations). For example: a building <can have as aspect a> number of levels.
5. Dictionary (Definition Models).
An Electronic Dictionary defines the kinds of components, kinds of documents, kinds of processes an kinds of properties, etc. in the application domain of the model. It defines the 'common language' of the Information Models. An electronic Gellish Dictionary is arranged as a Taxonomy and consists of Definition Models that define concepts by a model of the facts that are by definition the case. The Gellish English Dictionary is an example of such an electronic Dictionary.
Each element in a product and process model is related by a classification relation to a concept in the Dictionary.
Each document is related to a document type, which is also part of the Dictionary.
A product and process model, document models and a dictionary together form the core of a Facility Information Model.
A product and process model as well as the whole Integrated Information Model can be described as a network of related things (a semantic network). In other words it consists of 'objects' with relations between those 'objects'. Those relations include not only relations between components of the product and process model, but also relations between the components and the processes, activities, properties (including also shapes and coordinates) and documents.
Thus, an Integrated Information Model is the integration of a set of data and documents that model and describe a product and/or process, its use or operation and maintenance, whereas each component and each document is classified by a concept (a class) that is defined in the Gellish English Dictionary or its proprietary extension.
An integrated information model can be implemented in various ways. The essence is that the user of a system by which the data and documents are accessed should experience it as one integrated system. Nevertheless, the system may be constructed such that the documents are stored in a simple directory or such that they are be stored in a separate document management system and the data are stored in one or more databases.
The process to create an electronic Integrated Information Model will depend on the available material, the phase in the (project) lifecycle of the products or facilities and the intended scope.
The creation of an integrated Facility Information Model may start for example with the following source material:
The management of Bills of Materials, Equipment lists and Document indexes requires that revisions of those lists should contain an indication of each fact that is changed. This is necessary to enable a proper update of the database This means that it shall be indicated whether an equipment item or document is deleted, modified or added, relative to the previous version.
Typically the following steps are then taken to create the backbone of a Facility Information Model:
1. Create a facility composition hierarchy (also called an asset breakdown structure).
1.1 Make coded names (tag names) and unit names consistent and compliant with a standardized convention.
1.2 Classify components, equipment and units. This implies: Classify the site, the plant(s), process units, buildings, roads, systems and their components.
1.3 Decompose the facility. This implies: Specify for each component of which assembly (or assemblies) it is a part and add systems and include them in the decomposition hierarchy.
The result will be a Gellish expression format table. An example of the core of such a table is illustrated as follows:
B1 <is classified as a> building
B1 <has as part> C1
C1 <is classified as a> HVAC system
C1 <has as part> C2
C2 <is classified as a> cooling unit
2. Specify document auxiliary data (meta data) and file names.
2.1 Make document titles consistent.
2.2 Classify documents. This implies: Classify each document by standard document types.
2.3 Decompose documents where appropriate. This implies that for some documents (e.g. binders or multi-page drawings?) a decomposition shall be specified.
2.4 Add version succession of documents. This implies that documents that are succeeded by new versions shall be related to their successor.
This step and also the followings steps also result in a Gellish Database table.All those tables together form the Facility Information Model.
3. Relate documents to equipment.
Specify for each equipment item on which document it appears, or for each document about which equipment items it contains information.
4. Relate documents to files at addresses.
Specify for each document on which a physical medium it is presented, either as an electronic data file or on paper, microfilm or any other medium.
5. Identify installed items and relate them to designed items.
Specify for each installed item for which design item (tagged item) it is installed and identify the manufacturer’s models that are applied.
6. Add activities and processes (functions).
Specify which processes (functions) are or will be performed in or by the facility and its components and which activities are performed by people that operate or maintain the facility and its components.
7. Add aspects to the components.
Specify the properties, qualities, dimensions, shapes, coordinates and other qualitative and quantitative aspects of the facility and its components and possibly to the activities, processes and products.
8. Add other facts (relations)
Specify additional information as required to complete the specification.
Once the Gellish Expression format tables are created they can be directly used by a Gellish Viewer to search for information and documents about the facility and its components. They can also be exchanged and combined with Gellish Expression format tables that contain additional information about the facility.
Continue with Product Modeling