5. Generating and Executing Queries

Queries can be specified via the user interface or can be generated from a product model. The Query module is intended to generate queries via the graphical user interface as is implemented via two options in the QueryWindow. The first option is by a search for an 'object in focus' (via the 'Search' button) the second option is by a search that is specified by a collection of one or more Gellish expressions (via the 'Query' button).
Questions can also be formulated by an application system, such as a design system. Such a procedure uses a model of an individual object that has aspect values or constraints and from that it derives a query for kinds of things that satisfy the values for the aspects of the individual object. That option is also implemented in the Communicator. It demonstrates how a query via an application system works. Details can be derived from the implementation in the 'Formulate_query_spec_for_individual' method.
The queries are transformed from an application system or a user interface data structure into a Gellish Query. The resulting query expressions can be exported as system independent Gellish Expression Format tables in some serialization, such as CSV or JSON. A query can also be imported or directly executed by the Communicator.
A specification of a question in Gellish is an expression that has as intention 'question' or 'query specification'. The semantics and syntax of a query is the same as for statements, apart that in queries it is allowed to use names of unknowns.

Intelligent querying

A key feature of Gellish is the taxonomy of kinds in its dictionary (the subtype-supertype hierarchy of concepts). That taxonomy enables that a query for a kind can also search for the subtypes of the kind and all data about those subtypes. The kinds of relations are also arranged in the dictionary as a taxonomy. This enables that the search algorithm can also search for subtypes of possibly specified kinds of relations and for possible criteria for kinds of parts or kinds of aspects.
Furthermore, the taxonomy implies that subtype kinds inherit the property values of their supertype kinds. Therefore the search results will include all inherited data about the supertypes of a found kind. Thus searching for 'three core cable' executes a search that finds all its subtypes, including manufacturer's models and their specifications, and it will find all aspects that are inherited from its supertypes, such as 'electrical cable'. Because of the amount of search results and the various perspectives of users, the Communicator displays various views on the resulting model(s). It also provides a Gellish Expression Format tables output of the results, which can be exported and send to users or imported in application systems of users.

Suppliers catalogue items

For finding product types in supplier catalogues the Gellish queries can be sent to application systems of suppliers. The those system independent queries should be interpreted by the suppliers systems and their response can be returned either as Gellish expressions or in their own format. The Communicator has implemented an example of Mapper software that converts JSON files in a proprietary format into Gellish expressions, guided by a dedicated 'mapping table' (see the 'Interpret_non_gellish_JSON_file' method of the Expression_list class). Thus the Mapper software of the Communicator provides guidance on building such interfaces.