Page History

...

A ship design always contains a layout with at least a hull and defined reference planes. The entities Decks and Bulkheads will be optional for a user to include in their ship design.

Entity Hull

• Include the following two entities:

Entity Main Dimensions

The user will be asked to provide input values in entity Main Dimensions for the following parameters:

2.3.2.1     Creation of parameters

Right click in the right field of the Knowledge Browser and select “New Parameter/function..”, see Figure 49, which opens the Parameter, Object, Function or Document window.

...

In the same way you have to include the VR parameters “Lpp”, “Boa” and “Dm” in the Knowledge Browser.

2.3.2.2     Create classes to order your knowledge

You can create tree nodes in the Knowledge Browser, in order to group parameters, objects and relations. This is only a way to order your knowledge and has no functional meaning during the use of knowledge.

...

When you have created the classes you want, you can simply drag and drop the parameters and/or relations to the desired class.

2.3.2.3     Including parameters in an Entity

Now we have created parameters in the Knowledge Browser. The next step is to include these parameters in Entity “Main Dimensions”. Two ways are available to include parameters in an Entity:

...

The second method to include parameters in an Entity is by means of the select option “include parameters from knowledge base” while in the Entity Editor. After closing the Entity Editor Quaestor presents a list of parameters that are defined in the knowledge base. All selected parameters will be included in the newly created Entity. This is especially convenient when a lot of parameters are already available in the knowledge base the moment you create a particular Entity.

2.3.2.4     Affect presentation sequence of parameters

It can be desirable to affect the sequence of parameters presented in the Workbase list during a dialogue. Normally Quaestor presents parameters in an alphabetical sequence. An @ORDER attribute in the Data Slot of a parameter defines the relative position of a parameter in the Workbase list. Define this position by: @ORDER:RelativePosition, in which RelativePosition is an integer. The higher the value of RelativePosition, the later the value is placed in the list. The @ORDER values of parameters to be presented need not to be subsequent values. Parameters are sorted on RelativePosition. Values with no @ORDER attribute are placed behind parameters with the @ORDER attribute.

...

Figure 56: Loa on top of the list because of @ORDER: 1 in Data Slot of parameter

2.3.3      Entity “Hydrostatics”

Create the following parameters (all are values) within the Knowledge Browser.

...

Figure 57: Include parameters in Entity "Hydrostatics"

2.3.3.1     Create drop down box for parameter Rho

Because we want to provide only two options for parameter “Rho” (1.025 or 1.000 [t/m³]), it is useful to create a dropdown box. This can be done by providing the reference text as indicated in Figure 58 in the Frame Viewer. (This is also why the table above showed this as reference text for Rho).

...

Please note that you can create additional class nodes to order your parameters in the knowledge browser, see 2.3.2.2 Create classes.

2.3.3.2     Create Entity relations

In the “Hydrostatics” Entity we want to perform calculations based on information from “Main Dimensions” and some relation. In order to achieve this, we have to create so called Entity-relations. The first Entity-relation to create is for parameter “Boa” in Entity “Hydrostatics”: the value of “Boa” in Entity “Hydrostatics” should be equal to the value of “Boa” in Entity “Main Dimensions”.

...

Create “Volume” using the first method. The second method will be used for parameter “Displacement”, which is explained below.

2.3.3.3     Connect relation in Knowledge Browser to a parameter in an Entity

Start with creating one or more relations in the Knowledge Browser.

...

Furthermore, please note that it is still possible to create a new taxonomy relation by selecting the first option in presented window.

2.3.3.4     Provide the possibility to enable users to modify calculated values

In the first part of the tutorial, with parameter “Volume”, it was shown that it is possible to enable the user to modify calculated values after they are determined by the system. We can enable this functionality by adding a @MODIFY attribute to the data slot of the parameter.

...

Figure 68: Provide parameter "Volume" with a @MODIFY attribute

2.3.3.5     Define minimum and maximum values for parameters

Another interesting feature to assist the user is providing feedback about minimum and maximum input values. Moreover, you could make these boundaries into hard ranges in order to protect the user against providing value that might cause faulty results.

...

@MAXVAL:1.0
@MINVAL:0
@HARDRANGE

2.3.3.6     Show computed values during the dialogue

To show computed values during a dialogue you have to include the standard Quaestor parameter “QEntityData” (with the drag and drop functionality) from the Knowledge Browser in Entity “Hydrostatics”. You will find the parameter by either typing its name in the search box of the Knowledge Browser (field 1 of Figure 32). Or go to the top node of the tree in the Knowledge Browser (with the name of your knowledge base) and search in the list on the right side.

...

Figure 69: Entity "Hydrostatics" in taxonomy

2.3.4      Strategy for adding relations in taxonomy type of knowledge bases

Before we continue with the next Entity, we want to give more insight in the creation of relations in taxonomy type of knowledge bases. In the previous paragraph you have noticed that we created Entity-relations, paragraph 2.3.3.2 above and “normal” relations, paragraph 2.3.3.3 above. But why do we have two different methods?

...

1. The general approach is to create Entity relations when you are developing a Taxonomy type of knowledge base. 
   Only used normal relations when you want to use the modeling/reasoning functionality of Quaestor. You might want to use the modeler when you want to execute complex models which make use of reasoning an advantage over a normal traditional fully hardcoded model (which a Taxonomy is to some extent). This is the case when you want the structure (network of relations) of a model to be dependent on the choices made and input provided by the user.
2. The main reason to use normal relations and connecting them to parameters in an Entity is when you know that the relation will be used on multiple positions in the Taxonomy. In that case you rather create one relation and connect it to the parameters in the relevant Entities.
3. Use the ENTITY# function only in combination with Entity relations. You can use this function in normal relations but this is not advisable. The reason for use only in Entity relations is that, in case of an Entity relations, the EntityID in the ENTITY# function will be renumbered when modifications are made to the Taxonomy that cause Entities to be renumbered. This renumbering in the relation will not take place for normal relations.

2.3.5      Entity “Reference planes”

First create the following Entities as a child of Entity “Reference planes”.

2.3.6      Entity “Transverse planes”

We want to create the possibility for the user to define a table containing a number of transverse reference planes. In section 4.6 of the first part of the tutorial, the goal for Entity “Transverse planes” is described in detail.

...

Figure 70: Parameters in Entity Transverse planes

2.3.6.1     Let a parameter change the number of cases in an Entity

We will use parameter “Nr” to indicate the number of cases (columns) in an Entity.

...

Moreover, for integer value you could also change the number of decimal places to 0.

2.3.6.2     Force parameters to show in the table (make parameters multi case)

Normally, any single (constant) value is placed in the list view, see Figure 4.

...

Figure 72: Parameters with @MULTVAL attribute in Entity Transverse planes

2.3.6.3     Relation for X position of transverse reference plane

Select parameter “X” in Entity “Transverse planes” in the Workbase. Select the right mouse button menu Taxonomy>Choose/create relation or press Ctrl+T. Create the following relation:

...

For each case, representing a transverse reference plane, this relation will be calculated. Parameter “Frame_spacing” does not contain a @MULTVAL attribute, thus the value provided for “Frame_spacing” will be constant for each case.

2.3.6.4     Provide default values

It is possible to provide a proposed default value for “Frame_spacing” in the solution that can be overruled by the user by simply providing this value for the parameter in the Entity. For example, type 700 in the value cell of Frame_spacing”.

2.3.6.5     Use of ORCA() function to calculate numbers for each case: CaseID

Select parameter “CaseID” in Entity “Transverse planes” in the Workbase. Select the right mouse button menu Taxonomy>Choose/create relation or press Ctrl+T. Create the following relation:

...

Please note that you also could have made a relation in the Knowledge Browser and connect it to the parameter (the second method for Entity relations, see 2.3.3.2) because you will use the same relation for the horizontal reference planes.

2.3.6.6     Include standard Quaestor parameters: QEntityData, QEntityDoc and QEntityRef to illustrate and describe the Entity

Include (with the drag and drop functionality) from the Knowledge Browser the standard Quaestor parameters “QEntityData”,“QEntityDoc” and “QEntityRef” in Entity “Transverse planes”. These parameters will not be visible for users of your knowledge base.

...

• Comparable to assigning reference to a parameter, you can assign a reference to an Entity. Behind the included “QEntityRef” you can assign an unlimited Entity reference text, which will be shown in the html Explanation window. For example; “Define number of transverse reference planes”

2.3.6.7     Define a Entity specific presentation name for a parameter

You can use a @WBNAME parameter attribute to define a presentation name to the user. For example, you want to define a presentation name “Number of transverse reference planes” for “Nr”.

...

Figure 74: Entity "Transverse planes"

2.3.7      Entity “Horizontal planes”

The explanation for this paragraph will be extensive than the previous, because most of the actions that have to be performed are equal to the actions described above.

...

Figure 75: Entity "Horizontal planes"

2.3.8      Entity “Decks”

Entity “Decks” will be developed as a container which contains combined data of all defined singular decks below. As child of Entity “Decks” we include the multiple (select one of more) Entity “Deck”.

...

We will include relations for these parameters at a later stage (in paragraph 2.3.10), because these will be clearer to you when you first have developed Entity “Deck”.

2.3.9      Entity “Deck”

• Create the following parameters in the Knowledge Browser.

...

How to connect the start and end position to the reference planes will be discussed next.

2.3.9.1    Create selection list of reference planes with @SELECTENTITY attribute to position deck

We want to create a selection list from available data to position a deck according to specified reference planes in the reference Entities.

...

• Z = ENTITY#(15).Z.Z_plane_ID

2.3.9.2     Provide @OBJECTTITLE to a multiple Entity like Deck

As shown in Figure 21, each Entity node name of a Deck contains the name and height of a deck. This can be developed by using the attribute @OBJECTTITLE in parameter “QEntityData” of Entity “Deck”. Behind this value you can provide a flexible string, for example.

...

To add the @OBJECTTITLE attribute to QEntityData, double click on the parameter value. The content will open in a larger Quaestor text editor.

2.3.9.3     End result Entity “Deck”

The end result of Entity “Deck” is presented in Figure 77.

...

Please note that you can always change the presentation sequence of parameters by using a @ORDER attribute, see section 2.3.2.4 of this part. You can include presentation names for parameters which differ from the parameter name itself as explained in section 2.3.6.7. In Figure 77 this is done for parameter “Name$”.

2.3.10   Create relations in Entity “Decks” which combines data from child Entities below

We want to create a table with a subset of parameter values of all defined decks. The QEntity() expression collects parameters of all child entities.

...

• Add the “QEntityRef” and “QEntityData” parameters to “Decks”;
• Assign the following text for “QEntityRef”; “Combined data of all decks” as explanation to the user.
• To show computed values during a dialogue write “@SHOW” behind “QEntityData”.

2.3.11   Entity “Bulkheads”

As mentioned in the first part, this ship configurator uses a different Entity structure for defining (transverse) bulkheads in comparison with defining decks. Of course the same Entity structure could be used, but it is more instructive to present (and develop) a different approach.

...