Engine Default Behaviour
Rainbird’s Engine follows a default order when trying to make a decision using the conditions of a rule. This order is as follows:
Match
- Rainbird will look to see if it already knows of a fact between two instances. Rainbird will look at facts that exist within a knowledge map, previously inferred or answered facts, or facts stored in datasources.
Infer
- If Rainbird does not already know a fact, and a rule exists on the relationship Rainbird is trying to create a fact with, Rainbird will use the rule on the relationship to attempt to infer a fact.
Ask
- If a relationship is configured to allow a question to be asked and Rainbird cannot Match or Infer the required fact, Rainbird will Ask the user to provide the subject/object part of the fact, or to confirm a fact that Rainbird assumes is the required fact.
Plural Relationships
If a relationship is configured to allow multiple facts (a plural relationship) Rainbird will always seek to create more facts where it can.
- Match – Rainbird will look for any additional facts
- Infer – Rainbird will try to infer any further facts
- Ask – Rainbird will ask the user if they know any additional facts
Certainty and condition/relationship ordering
Rainbird’s Engine looks for the most certain answers and will take the quickest possible route through a query to an answer. This means that if Rainbird has more certain facts or rules with higher overall certainty it will look at these first.
The same is true of conditions that relate to more certain facts or rules with higher overall certainty. By default, this can mean that Rainbird will skip over conditions in rules to prove or disprove a rule in a more efficient way.
Rule Behaviour
You can change the order Rainbird will consider the conditions in a rule by opening a rule, clicking advanced, and changing the behaviour in the ‘Condition ordering‘ box. By default, the ‘Condition ordering’ will be set to ‘Default’ (see Certainty and condition/relationship ordering above).
If the behaviour is set to default, particularly on plural relationships, Rainbird may seek to get all possible answers and explore many lines of inference, which may affect question wording/ordering.
The benefits to these behavioural changes are:
- The way Rainbird infers an answer, and therefore the Question wording can be controlled
- ‘Fail Fast’ mechanisms can be employed to increase engine efficiency
- Unnecessary questions are not asked if they are not relevant to the rule or line of questioning
Figure 1: Changing the Condition ordering
Top-Down vs Top-Down-Strict
If Condition Ordering is set to ‘Top Down‘, Rainbird will look at the conditions of a rule in order from top to bottom. Rainbird will still be able to skip a condition if it cannot match, infer or ask to find an answer to fulfil the condition. As soon as Rainbird can match or infer the answer, Rainbird will return and process the conditions in a top to bottom order.
You may want to set a rule to have ‘Top Down’ behaviour if a rule has an expression that needs to be completed as soon as possible, but the variables required for the expression come from various sources (facts, datasources or inferences). If the rule behaviour is set to ‘Top Down’, and the expression is at the top of the conditions in the rule, the expression will be completed as soon as all the variables required are available.
If Condition Ordering is set to ‘Top Down Strict’, Rainbird will look at the conditions of a rule in order from top to bottom, however if a condition cannot be processed in the given order via match/infer/ask, the rule will stop and cannot be returned to as a line of inference.
You may want to use ‘Top Down Strict’ behaviour if you are setting up a query where some questions or lines of inference may only be relevant after certain gating conditions have been met. If the gating conditions are placed at the top of the rule, and the behaviour is set to Top Down Strict, if they are not met, Rainbird will not ask the other questions in the rule as they may be irrelevant.
The RBLang below will generate a map that uses ‘Top Down’ and ‘Top Down Strict’ behaviour. Click on ‘Export .rbird’ to download the knowledge map.
Query and Results
In the model generated by the .rbird file, there are rules that require Top Down and Top Down Strict on the relationship ‘application has been’.
- There are two ‘Top Down Strict’ rules that take different lines of questions if the type of permit selected is either ‘Music Event’ or ‘Food Stall’. Queries where ‘Music Event’ is selected won’t ask about the food type and queries where ‘Food Stall is selected won’t ask about the musical requirements.
- There is an example of a ‘Top Down’ rule, with the expression as the top condition on a rule where the permit type is ‘Parking’. This rule maintains a set question ordering but would have failed if the rule had have been Top Down Strict.
