Query Manager

LegendBurster stores all queries, and also stores their results. It processes queries in a batch mode, allowing collections of queries to processed together. This is most useful for queries that take a long time to process, either because of the size of the data set they are applied to, or because of the complexity of the ontology or the query - or because of a combination of these factors.

The Query Manager is used to control the creation, editing and processing of queries.

Central to the operation of the Query Manager are the lists of un-processed and processed queries - both of which will be empty for a new project.

Creating new queries, an action initiated from Button (1) in the illustration below, is described in the section entitled "Constructing Queries".

Once some queries have been created, they will appear in the "Un-Processed Queries" column (Item (2)), where they can be selected for processing by clicking in the appropriate checkbox (Item (3)). Clicking on the "Process Queries" button (Item (4)) will initiate processing with the system's default query control (QC) parameter settings (Items (4a), (4b) and (4c)).

The "Normalise Query Score" parameter simply requests LegendBurster to scale the worst-to-best scoring range from 0 to 100. Since different queries can lead to different maximum and minimum scores, scaling them all to a constant range makes results easier to interpret. This parameter can, however be set not to normalise the scores, in which case absolute scores are recorded. This can be useful when investigating unexpected results.

The "Silence Implies Absence" parameter is more complex, and determines how the system responds (in terms of rewards or penalties) to attribute/value pairs that are present in one object, but not present in the object to which it is being compared. If the query is being processed under "silence implies absence" conditions, an un-matched attribute/value pair will attract a penalty to the comparison underway, equivalent to the appearance in the compared object of the same attribute/value pair, but with the "Presence status" of "Absent". If "silence implies absence" was not in force, then the un-matched information would either attract no penalty or reward, or attract a small penalty, depending on the setting of the "Penalties for information outside scope" parameter.

The importance of this parameter derives from the fact that, very often - but not always, observers record only the attributes of an entity being observed which are seen to be present. If this is generally the case for the group of entities being compared, then more accurate similarity-rankings may result from applying the "Silence implies Absence" assumption, than by not applying it. Interestingly, it is often the case that, the more an observer knows about the class of entity being described, the more "negative" information they will record, because they have the knowledge to know which negative attributes are relevant, amongst the infinite range of negative attributes which could be recorded.

The final parameter relates to applying small penalties to mapObjects which have (recorded) attributes beyond the scope of the query. It provides another way of dealing with absent information - this time with (an asymmetrical) focus on information in the mapObject that is not in the query (and therefore considered "down-grading of the match" under particular circumstances, which may relate simply to how the data was collected, rather than the logically purest way to reason).

This parameter's practical effect is best demonstrated by considering an example where a query is compared with two objects, the first with a description which exactly matches the query, and the second with a description which matches the query, plus one additional attribute. With the "out of scope attributes implies small penalties" assumption, the second object would be recorded as a marginally poorer match to the query than the first - affecting little more than the order in which they would appear in the Scores Viewer. When evaluating a group of similar objects, ordering them inversely to the amount of superfluous (?) information recorded about them can sometimes be helpful.

Once processing is complete, the names of the processed queries will appear in the "Processed Queries" list (Item (5), and they will be ready to evaluate in the Query Results Viewer, which can be activated by clicking on the "Go to Query Results Viewer" button (Item (6)).

Should a query need to be re-processed under different QC conditions, it may be transferred to the "Un-Processed Queries" list by placing a tick in its checkbox (Item (7)) with the mouse, and clicking on the "Move Selection to Un-Matched" button (Item (8)).

IMPORTANT NOTE: If any changes are made to any of the mapObject semantic nets, all queries will automatically be transferred to the "Un-Processed Queries" list, because their scores or relative similarity rankings may have been affected by the changes.