Page tree
Skip to end of metadata
Go to start of metadata

The traditional knowledge domain of Quaestor is a semantic network of frames containing Relations, parameters and Constraint (see figure).

A frame is a representation unit of an object and its slots contain knowledge of the object. Each frame contains a type slot, which makes it possible to determine its Relationship with other frames. Other slots contain properties of the frames, background information (reference), data etc.

The above representation in combination with an inference engine makes it possible to assemble a computational model for a particular set of top goals. A great advantage of this approach is that only by defining mathematical relationships in a knowledge base, computational models can be configured for any combination of goals and input fitting within the domain of the knowledge base.

In a way, the formidable flexibility of this approach is also its weak point, in particular when we are aiming at the group of users that desire dedicated but complex applications, e.g. in the field of propeller design, sea keeping analyses or conceptual ship design. The Modeler of Quaestor assembles an application by interpreting and combining the frames in the knowledge base. This means that the sequence of input requested to the user is determined by the structure of the relations and the constraints in the knowledge base and that it is relatively difficult for a knowledge engineer to prescribe the sequence and grouping of input proposed to the user. This aspect becomes increasingly important in environments where Quaestor is used as a platform for controlling complex calculations that were previously executed as stand-alone application. By encapsulating these tools in a Quaestor knowledge base, any calculation performed with these (collection of) tools becomes a managed set of data and objects that can be accessed through Quaestor and database systems.

In order to allow Quaestor to represent knowledge about the sequence of computational process, the Taxonomy concept was introduced.

Taxonomy Entity concept

The term Taxonomy has been borrowed from biology and describes the hierarchy of life on earth. In Quaestor a Taxonomy is a hierarchic structure of Entities (see also [wikipedia]).

An Entity is a Quaestor object that contains parameters that are either input, goal or to be computed with a particular relation. The relation can be a classic one or can be encapsulated in the Entity in which it is used. Any Entity contains at least a user defined name (QEntityName), a unique ID provided by Quaestor (QEntityId) and an index (QEntityIndex) in case of multiple instances. Any Entity may contain an image or (html) document providing additional explanation (QEntityDoc).

The Taxonomy and Entity use Quaestor's capability to already deal with complex object data structures. A Taxonomy can be a generic description of an object (e.g. a ship structure) or a process (e.g. the design of a ship hull and/or the generation of a stability manual). So, a Taxonomy contains knowledge about the structure of a solution based on that Taxonomy. In a way the Taxonomy represents the DNA structure or blue print of the solutions that will be based on it.

The Taxonomy-Entity concept is now used as paradigm for the development of new knowledge systems and provides important benefits, both for the Knowledge Engineer and the users of the knowledge systems. It facilitates the communication between knowledge engineer and users and results in more simple and maintainable solutions.

  • No labels