Behaviour: Optional / Mandatory

Behaviour: Optional / Mandatory

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 optionalinstead 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:

 

ConditionsCase 1Case 2Case 3Case 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:

  1. 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).
  2. 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).

Click on the ‘Export.rbird’ button to download the ‘Optional/Mandatory’ map used in this example. The knowledge map can then be imported into your Rainbird Studio.

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.

Article Feedback form
Did you find this article useful?

Version 1.01 – Last Update: 18/02/2021