Gellish Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Semantic Modeling ======
The **Gellish Semantic Modeling Methodology** is a methodology for creating integrated information (models) that basically covers the modeling of the following area's:

  * A formal language definition, in the form of Gellish expressions that define a taxonomic dictionary and ontology of concepts.
  * Modeling of knowledge and requirements
  * Information about individual products and processes.
  * Integration of documents and files



====== 1. The creation of Integrated Information Models ======


Integrated Information Models are models with expressions of information about individual objects as well as about kinds of objects and definitions and may also include documents and requirements. The models may consist of data and documents about imaginary objects, such as designs of objects, and may also include data and documents about real world objects, such as geographic objects, organizations and persons, organisms and realized facilities and may includes expressions about their processes and activities, operation and/or maintenance. The integration does not only refer to the integration of various above mentioned categories of information, but it refers also to the seamless integration with other models that are expressed in the same formal language. The latter only requires a proper management of the unique identifiers (UIDs) of the user defined objects.\\

The Gellish Modeling Method provides guidance on how to create such Integrated Information Models in a neutral computer interpretable form. The models may be stored as a Gellish Database, which means that the database structure for such models universal and readily available. The models may also be stored in proprietary databases. In the latter case each system requires a 'Mapper', being a transformer of Gellish expressions into a native format and vice versa. Guidelines for such Mapper software is given in the section about [[gellish_messages|Gellish messages and interfaces]]. It should be note that it may be the case that application systems cannot store the whole of the semantic richness of the Gellish expressions, which may result in loss of information during the mapping process.\\


A resulting Integrated Information Model will usually include the following sections: 
  - A product and/or process model
  - A collection of document models
  - A taxonomic dictionary
  - Collections of possibilities for kinds of things
  - Collections of requirements for kinds of things in particular contexts

Each of these sections is briefly described below and is described in further detail in the indicated sections of this wiki. They are extensively discussed in the book 'Semantic Information Modeling Methodology'.
===== 1.1 Product and process models =====


A model of one or more related facilities, products and or processes includes characteristics and classification of the included objects and their components and processes. For example it may include geographic objects, buildings, roads, ships, process plants, railways, cars, etc. as well as their components, such a pumps, pipes, cables and vessels, up to components such as nuts and bolts as well as fluids and gases in and around them. It also may include their characteristics, roles, connections, functions, movements and processes in which they are involved and the people and organizations and other stakeholders and their roles and activities. 
Further details about creating facility, product and process models are given in the [[product_modeling|product modeling]] section of this wiki.


===== 1.2 Document models =====

A document and data sets repository with the data sets and documents, including also electronic drawings and 3D model files about the components in the facility and product models with relations to the components, so that the facility models and product models can be used to search for the data and the documents about them. In the inverse direction a document can provide the typed links to the objects that are mentioned of described in the document. For example schematic diagrams may have intelligent links to the objects that are represented by symbols on the drawing, whereas values of characteristics on the drawings may be extracted from the product models.\\

The partial or complete modeling of the content of textual documents is also possible in Gellish. A first step towards that is the splitting a document in pieces of text, such as paragraphs, whereas those pieces of text are objects that are included in the integrated information model. The pieces of text can be combined in composition models of the documents. This enables for example that a piece of information appears multiple times in different documents or related to different objects, whereas it exists only as one object with its own UID in the semantic model.\\

Further details about creating document models is provided in the [[document_management|document modeling and document management]] section of this wiki. 


===== 1.3 A Taxonomic Dictionary (definition models) =====


A Taxonomic Dictionary is required as integral part of a model in a formal language, because the individual components, their properties and documents will be classified by standard concepts (classes) as defined the Gellish Dictionary. The kinds in the dictionary act as the glue between expressions of knowledge and requirements and the individual things for which the knowledge and requirements are applicable. The consequence of using the dictionary for all categories is that an Integrated Information Model is expressed in a consistent common language that enables integrating data from various sources, and it also enables very powerful searching and computer augmented verification whether things satisfies requirements, especially by making use of the knowledge, definitions and specified requirements that are contained in both the Gellish taxonomic dictionary and the parts of the integrated information model. 

**Domain dictionaries and taxonomic dictionary extensions**

The standard Gellish Taxonomic Dictionary may not be sufficient for a particular application domain or some organization may want to maintain and use their own dictionary as a replacement of one or more sections.
For that purpose the methodology describes the development of [[:gellish_english_dictionary|Taxonomic Dictionaries]]. A taxonomic dictionary for a particular domain consists of a collection of Definition Models, each of which defines a concept, whereas all concepts are arranged in one integrated subtype-supertype hierarchy, which includes also the Gellish base ontology at the top of the taxonomy. \\  
The methodology describes the expressions that together define concepts through statements that express what is by definition the case for the concepts. The expressions about one concept forms a computer interpretable Definition Model of that concept. Each Definition Model includes at least a subtype-supertype relation, a naming relation and a textual description of at least one aspect or component or suitability for a particular function that distinguishes the defined concept from its supertype concept and from its neighboring concept(s). This ensures that the concepts in the dictionary are arranged in a taxonomy structure. A Definition Model also includes the specification of one or more names, synonyms, abbreviations, symbols, etc. to denote the concept in one or more languages and contexts (language communities). When the defined concept is an activity or process, its definition model may include relations to kinds of objects that are by definition involved in the occurrence in a particular kind of role.\\
Note that a concept itself is represented by a UID only, without any 'attributes' or relations, even from its name(s). Thus a concept is distinguished from a definition model about the concept. A definition model in a dictionary also does not include any specification of possibilities or requirements. Such specifications are expressions that can be integrated with definitions, but do not belong to the definition of a concept. N.B. A concept as well as a definition model in Gellish thus differs from the conventional definition of entity types or objects types in data models, because entity types and object types are in fact collections of data about a concept, whereas there are no constraints on the information about the entity type that may be included in attributes or methods. \\

The methodology describes how to define kinds of physical objects as well as kinds of aspects and aspect values (also called qualitative aspects), kinds of roles, kinds of activities and processes, etc. The qualitative aspects can be used for defining concepts and for qualifying individual characteristics. Furthermore, the methodology describes how to define kinds of relations. \\

A Definition Model forms a small semantic network of related concepts, possibly consisting of only a subtype-supertype relation and a naming relation. A collection of Definition Models forms a larger semantic network of concepts that composes the Gellish Taxonomic Dictionary. Additional guidelines for the creation of Definition Models can be found in part [[dictionary_extension|Domain Dictionaries and Dictionary Development]] of this Wiki.
===== 1.4 Knowledge about possibilities and requirements =====


An integrated information model may include a collection of expressions of requirements and knowledge about possibilities for things of specified kinds. Such expressions of requirements and possibilities apply to kinds that may be the classifiers ob things in the first and second section of the integrated information model, being the product, processes and documents and their characteristics. This implies that the knowledge and requirements are applicable for the classified individual things. This enables the usage of the possibilities and requirements for guiding design processes or for verifying models on completeness, conformity and other information quality aspects.\\

**Modeling and use of knowledge**\\

The methodology for modeling of possibilities is about the expression of knowledge about what can be the case for things of particular kinds. For example, the formal language enables expressing possibilities for decomposing objects of particular kinds in components of particular kinds and the possibility that such objects or their components can have characteristics with values of particular kinds. Possibilities are expressed in Gellish by creating relations between concepts, whereas those concepts shall first be defined and included in the Gellish Dictionary or in a proprietary extension. Knowledge Models are in fact extensions of the Definition Models through which the concepts are defined, because knowledge about possibilities add ideas about what can be the case to ideas about what is by definition the case. Collections of expressions of knowledge about various kinds of things in a particular domains are often called an Ontology for that domain and may be included in 'Knowledge Libraries', also called an 'Object Libraries'. Guidelines for such knowledge libraries are for example also provided in the ISO Standard 16354 'Guidelines for Knowledge Models and Object Models'. The Gellish Modeling Methodology also describes how modeled knowledge can be used. For example, for guiding design processes or for providing knowledge about standard solutions for designs.\\

A lot of knowledge is contained in textual documents or in pieces of text. Because the content of natural languages text is not expressed in the formal language, it is not 'modeled' and not computer interpretable, apart from possible hyperlinks or even 'typed links'. The relation between documents and data is described in the document modeling section as mentioned above. \\

**Modeling and use of requirement**\\

With //requirements// we mean requirements about kinds of things. For example, requirements for data and documents of particular kinds about facilities, products and processes of particular kinds that have to be delivered by contractors, manufacturers and suppliers that realize capital projects. Such requirements are usually applicable in a particular company or project context in which they are declared to be applicable. They may include requirements for data and documents about products, procedures and applications. Such requirements are expressed for example in best practices guides of companies, but also in national and international standards as well as in governmental rules. Usually such requirements are expressed in textual documents. The methodology provides guidance for the creation of requirements models that can be used for computer-aided support for the verification whether deliverables (such as designs or fabricated products) satisfies those requirements. \\  Standard Specification Models as well as Requirements Models use the concepts that are defined in a Gellish Dictionary.

The modeling of possibilities and requirements is further described in the section about [[knowledge_modeling_in_gellish|Knowledge modeling]] and [[requirements_models|Requirements modeling]] in this wiki.
====== 2. Creation and interpretation of messages between systems ======


The part of the Gellish Modeling Methodology describes how to create [[:gellish_messages|messages]] for the exchange fo data between systems. This includes messages that express [[:querying_a_gellish_english_database|queries]] to people or to query central or distributed databases, messages that contain responses with answers and messages with statements. The method describes how software should create and interpret (parse) such messages that are exchanged between Gellish enabled software. In other words, it describes messages for system independent communication via Internet through a [[:gellish_semantic_web|A Gellish Semantic Web]]. The creation of messages is further described in the [[gellish_messages|Gellish messages]] section of this wiki.


====== 3. Creation of Queries ======


Expressions that specify queries on Gellish databases are models in which unknowns appear for which constraints are specified. The methodology describes how such queries can be formulated. This does not require a separate query language, but the queries can be formulated in the normal Gellish formal languages.
The methodology also describes how queries should be interpreted and how they can be satisfied by software and how such software can be driven by 'mapping tables'. This is described in the section [[querying_a_gellish_english_database|Gellish queries]].





====== 4. Creation and use of models of Product types ======


Models of //product types// (also called 'standard specifications'), are specifications of definitions of standardized types of products or services and components of them of which a number of aspect values and possibly decompositions are predefined. Such specifications are standardized so that many individual things can be created that comply with those specifications. In some sense the specifications can also be interpreted as requirements for the creation of individual things. They are usually called 'products', although they are in fact //kinds of products// and not individual products or prototypes. They are specialized concepts with qualitative aspects and those concepts should be defined as subtypes of the concepts that appear in the Taxonomic Dictionary and should thus be treated as extensions of the taxonomy hierarchy. This implies that they will be found when searched via the more generic concepts in the dictionary.\\

There are many of such specifications defined and published as documents in national standards, such as ANSI, BSI, DIN or JIS standards or they may be defined by international standardization bodies, such as the EU, ISO and IEC. They may also be defined in company specific **product catalogues** as well as in libraries of 'typical designs'. For example, many standards institutes provide standard specifications that specify that particular kinds of things shall satisfy the specification in those standards in order to ensure a certain product quality or to prevent that they will be a health hazard. Sometimes those institutes provide the possibility that products can be certified when they satisfy the specifications. \\
The definitions of standardized product types differ from the specification of requirements, such as requirements that are expressed by governments or other organization, because such requirements only specify what shall be the case according to the authority and do not guarantee that the product type is defined to be as specified.


The Gellish Modeling Methodology provides guidelines for the expression of definition models about such standard product types and component types. The methodology also provides guidance on the use of such models, for searching in the taxonomy and selection based on requirements (queries) with specified characteristics, for example for procurement, but also for integration of those models in designs, either by classification or by retrieving characteristics values from the selected product types.


Note that a standard specification model is not a [[:Product Modeling|product model about an individual object]] nor a model of a 'typical individual thing' or a prototype, but a standard specification model defines a kind of thing, whereas that kind is used in situations in which the specification is declared to be applicable.\\


This description of the creation of models for product types is among others intended for transforming product catalogues of manufacturers and suppliers into a generalized neutral electronic formal language for usage in e-commerce. Conventionally this is done in proprietary formats, whereas those formats are typically dedicated to a particular application domain, which is costly and puts unnecessary constraints on their applicability. The methodology is also intended for the conversion of standards for product types from national and international standards organizations, which are currently still published in paper form and are usually not yet made available in a system independent computer interpretable electronic form.\\
The modeling of product types is further described in [[standard_specification_models|modeling of product types]].


//Continue with// [[:gellish_english_dictionary|Gellish English Dictionary]]
Gellish Wiki

User Tools

Site Tools

Page Tools
