Data use and management
In the article Image management (In de Quaestor Knowledge Browser: Quaestor>Topics>Technical documentation) and QBinaries, it is described how to create, maintain and access a collection of images or documents that are presented when a particular parameter or value is in focus in the Knowledge Browser or Workbase. In this article we will depart from this mechanisms and zoom in on the possibility to create (binary) databases and use them (by performing selections) during the modeling process.
A Dataset of a knowledge base may contain a set of objects with all kind and different types of data. During a modeling session, selections from these objects can be made for a variety of purposes. The mechanism is illustrated with the selection of ship hullform data.
Example 1, Use of data in the dataset with an |OPTION| script:
Assume a hull form offset table your want to store in a parameter HullForm$ because it is needed as part of an input file for hypothetical software to calculate e.g. hydrostatic properties.
HullForm$ is determined by means of a relation:
HULLDATA# is the selected input set for the calculation and is defined by an |OPTIONS| script represented as a Telitab set in its data slot of the parameter:
Let us explain what you see in more detail:
The first line you see is simply an explaination (and not required).
The script between |OPTIONS|….| describes how, what and where to get the Telitab set you will refer to as HULLDATA#.
This particular script describes three selection steps through a dataset,
"Ship type" (represented by the data connected to parameter SHIPTYPE$),
"Order number" (represented by the data connected to parameter PROJECT$) and
"Loading condition" (represented by the data connected to parameter CONDITION$).
The "CAPTION" part is the presentation of the questions, the "OPTION" part is the link to the data in the data set that is used.
Please realise that the last item, "DATA"# "ParentShips", defines the reference for HULLDATA# to the actual total data set. This is the data set for the selection as described by the script. In this case the data is available in the ParentShips object.
During calculation the system will look for this object in the current solution. If not found, it will look in the Dataset of the project and if it is not found in the project either, it will look in the Dataset of the knowledge base.
The line "HullForm$" "" in the script tells the system that at least a DETERMINED value of HullForm$ should be available to allow selection of a case. This means, that the result of the selection cannot be empty values for HullForm$, therefor Quaestor will pre-filter all these cases out of the total dataset. The selection of HULLDATA# will contain all other DETERMINEDvalues available in the selected record. Also SHIPTYPE$, PROJECT$ and CONDITION$ should be DETERMINED (thus available) to allow a selection.
Optional use:
By using the QUERY# function with this syntax: QUERY#(0, Arg_1$[:ParLab_1$],,,,Arg_n$[:ParLab_n$]) for HULLDATA#, you can make sure that already available parameters will be used to pre-filted the options.
For instance when the ship type is already defined earlier in the solution, or is available as starting data in the dataset, you can add the relation HULLDATA# = QUERY#(0, SHIPTYPE$) to make sure that OPTION1 already uses the value for SHIPTYPE$.
Example 2, Use data in the data slot of the parameter with |OPTIONS| script:
As alternative method to select data, in stead of making a reference to an object as done with "DATA#" "ParentShips", you can include the data in the |OPTIONS|….| script of the parameter. This is done in the following example
Let us explain what you see in more detail:
@SUMMARY and @PICTURE are attribute, they manipulate the behaviour of the knowledge based system comparable to all the Slots&Properties. Using the @SUMMARY attribute you tell the system to display an overview of total selection made based on the dialog through de included data. @PICTURE tells that pictures should be displayed of which the references are given in the included dataset.
Again "CAPTION" and "OPTION" are the presentation and reference to the data. "SUMMARY" defines how the summary should be presented after the selection is made. Please note that the result corresponding with the summary number will be placed behind the text. Moreover, the order as they are presented in the scripts is the order of de lines as they are presented in the summary
By including "OPTION" in the the table, the database selection returns only a single value, being the selected case value of "OPTION" instead of all values related to the selection.
As mentioned the @PICTURE attribute defines that relevant picture information can be presented throught a references to these images. For "OPTION4" this has been defined. For example, table 1:twind1 refers to an image "twind1" in QBinaries object in the Dataset (QBinaries is a reserved Quaestor object that can be used to store all knowledge base fixed binary data, see Image Management in Quaestor>topics>Technical documentation>).
Please note that, if another object is used as data source (as is done in Example 1) referring to images in the QBinaries will only work if the parameters used in the refered object haveValue:Label as string values and a @PICTURE attribute in there dataslot.
Example 3, Use of binary data in the dataset with an |OPTION| script:
In the following we will show how to manage and access a set of binary objects. In this example we will enable the selection of components in a Rhinoceros configurator, a typical CAD application that can be controlled by scripts that are generated by Quaestor. The problem is related to the selection of component models on the basis of some selection criteria.
Similar to the procedures followed to create an image database in the Dataset.QBinaries object, it is possible to create any object in the dataset containing binary data using other than the reserved QBinaries, QBinary and QBinaryID parameters.
Please note that, in order to make any string parameter suitable for the storage of binary data, the only necessary action is to include the @BINARY attribute in the Data slot of the frame. A dataset can be created with the "Parameter to Dataset" menu option. Binary data can be included through the "Dataset>Include Binary Data" menu option after which a file dialog is invoked on the current active project directory and removed by means of the "Dataset>Remove " menu options (shortcut is Ctrl-B). Please note that only parameters of the String type can be used to store binary data.
In this example an object Dataset.RhinoComponents has been created containing the following parameters:
- Component$: a string parameter with the @BINARY attribute. In each value cell of this parameter in the Dataset.RhinoComponents an arbitrary file can be stored (see above). If the file is double-clicked or F2 is pressed, it is saved in the currently active project working directory and the associated program is started (in this case Rhino). If the file is changed in the associated tool and saved on the same location under the same name, Quaestor restores this modified file in the selected cell.
- Type$: an existing parameter defining the type of component, e.g. a "Hull form", "Crane" etc. This is the first selection key.
- Name$: the denominator of the component, e.g. Container vessel or Gantry. This is the second selection key.
Quaestor employs an internal database selection mechanism that can be defined through an |OPTION| script. In the following we will briefly explain its principles. In order to enable the selection of a hullform, the following |OPTION| script is included in the data slot of the parameter ComponentFile$:
Note: The text after ' is comment please do not use it in the knowledge base.
Although the object RhinoComponents contains both Name$ as Type$, it will not ask for the type if a value of Type$ is already available on the location at which a hull form file is required. So, if Type$="Hull form", the option dialog will not present the "Type$" options list and only leaves the choice for cases fulfilling Type$="Hull form".
This will also work for a larger number of selection keys of which any key with a DETERMINED value will not be presented in the selection dialog and are used as query arguments for the following sub selection. This is the way in which you can navigate and select in large collections of coherent options. An example is the QSTAP knowledge system for ship sea trial analysis in which a large number of ship- and condition dependent methods are to be selected from.
The above selection mechanism is enhanced with a mechanism that will immediately export any binary data stored in the final selection result. This implies that in the above example the binary data contained in the selected Component$ case will be exported to the currently active working (project) directory. There can be more than one binary datasets included in a selection; all will be exported assuming they will have unique names. In this way, you can ensure that particular data is available to any used satellite program (in this example the CAD program Rhinoceros) in which it is addressed by a Quaestor-generated script.
The optional @INITIFNOFILE attribute…
In the event that a knowledge base in which the above mechanism with binary data is applied, is copied and a solution is restarted using data already selected in the above described manner, some required files may not be present at the moment of executing a particular script. This may lead to some confusion that can be avoided by adding the @INITIFNOFILE attribute to parameters representing binary objects (such as the above example ComponentFile$). On restarting a solution using an Input object, parameters with the @INITIFNOFILE attribute will be checked on the availability of the file (of which the name is contained in the parameter) on the current project directory. If not available, the value is intialised and the selection dialog is re-invoked. After selection, the file is exported again.
The Input object is another reserved Quaestor object you can define together with the reserved string parameters Value and Parameter. By doing so, you will have an input recorder for object-related input, a typical requirement of configurator applications.
Selection of a single binary object...
In the event that a parameter represents a single, unique binary object, it is not necessary to use the above selection mechanism. In that event, the solution is to include the object in the frame as embedded object using the "Include Binary" in frame menu option (removal through "Remove " from frame menu option). If the value given to that parameter during a session equals the file name of the embedded object (without extension), the object is immediately exported under that file name to the current project working directory. This is an elegant and simple way to the storage and making available of particular files that are unique and can therefore be associated to a parameter.