When creating a rule in Rainbird, it is necessary to create conditions to ensure the rule will be triggered. Rainbird can treat the conditions in two different ways with the “optional” and “mandatory” behaviour settings. It is important for a Rainbird designer to understand how Rainbird will treat different conditions, as it will allow them to build knowledge maps with more precise logic.
Mandatory behaviour:
By default, a condition in a rule will be mandatory. If a condition is mandatory, the rule will only return an output if the condition in question is met. Meeting one condition doesn’t necessarily mean that the rule will output something – all mandatory conditions in a rule must be met.
Optional behaviour:
A condition can be set to ‘optional‘ instead of mandatory. An optional condition will allow the rule to return an output even if the condition in question is not met. If a condition is not met, the Certainty Factor of the outcome will be lowered proportionally to the weighting the optional condition has in the rule/final result. If the condition is met, the rule will provide an outcome (if the other conditions are also true) including the optional condition’s weight in the result’s CF.
Here is how to toggle on or off the optional behaviour in a condition:
Figure 1: Changing the mandatory behaviour of a condition to optional
The following table details how a rule with 2 conditions will behave depending on the conditions’ settings:
| Conditions | Case 1 | Case 2 | Case 3 | Case 4 |
| Condition A: Mandatory | True | True | False | False |
| Condition B: Optional | True | False | True | False |
| Rule outcome | True (CF 100%) | True (CF 50%) | False | False |
Figure 2: Table of truth of a rule depending on its conditions’ behaviour
Let’s illustrate how the different behaviours function with an example:
To demonstrate optional and mandatory condition behaviour, we have built a map that helps a prospective home-owner to filter between different houses they want to visit. A person may require a house to have certain features ( e.g. a fireplace, a garden), and will not want to consider houses without these features. Our Rainbird model will select from a long list of houses only the houses that correspond to the person’s requirements(for more information on how to build a map, please consult the Building in Triangles article).
We start by building the base of our model:
4 concepts:
- Person – string concept
- House – string concept
- Garden – boolean concept
- Fireplace – boolean concept
2 relationships starting from the “Person” concept:
- “Person” – “wants a fireplace” – “Fireplace” (singular, question on)
- “Person” – “wants a garden” – “Garden” (singular, question on)
2 relationships starting from the “House” concept:
- “House” – “has fireplace” – “Fireplace” (singular, question off)
- “House” – “has garden” – “Garden” (singular, question off)
1 final relationships that will be our query relationship
- “Person” – “wants to visit” – “House” (plural, question off)
A set of “House” instances with facts to represent the list of houses:
- The white barn
- “has fireplace” = false
- “has garden” = true
- The old post
- “has fireplace” = true
- “has garden” = false
- The lazy duck villa
- “has fireplace” = false
- “has garden” = true
- The little woodhouse
- “has fireplace” = true
- “has garden” = true
- The calm school
- “has fireplace” = false
- “has garden” = false
- The fierce oak
- “has fireplace” = true
- “has garden” = true
- The gleaming cottage
- “has fireplace” = true
- “has garden” = true
Here’s what the model looks like:
Figure 3: Preview of the model
We need to create a rule on the “wants to visit” relationship to make Rainbird infer which house to recommend to the user based on his preferences:
Figure 4: building the main query rule
Note: All the conditions are set to mandatory by default. If we query the model now, it’ll only propose houses that respect the person’s requirements.
If the person wants both a fireplace and a garden, only houses with both will be selected. If the person only wants a garden, then only houses with a garden and without a fireplace will be proposed. Here’s an example of query:
Figure 5: Query with mandatory behaviour
Let’s assume the person choosing the house doesn’t really care much about having a fireplace. He sees it as some kind of bonus, it would be a plus to have one but he would not dismiss viewing a house if it didn’t have one.
To reproduce this behaviour in Rainbird, we need to tell Rainbird that “House” – “has fireplace” – “Fireplace” is optional. To do that, we need to change the condition setting to optional:
Figure 6: Changing the relationship’s behaviour
Here’s how the model will behave now:
Figure 7: Querying the model with optional behaviour
Notes:
- Not wanting a fireplace is also optional now. If the person says he doesn’t want a fireplace, he will still be proposed with houses with a fireplace (with a lower CF).
- The CF of the houses returned with the optional condition not met is at 75%, due to the weighting of the conditions (4 conditions of 100 weight each, 3 are met out of 4).
The RBLang below will generate the map used in the example. Click on ‘Export .rbird’ to download the knowledge map, or ‘copy RBLang’ and paste the code directly into Rainbird.
Query and results
Please run the query on the relationship ‘wants to visit’ for a demonstration of mandatory/optional behaviour in action. The different query outcomes are explained in the article above.
