Rules tell Rainbird how and when a relationship between two concept instances applies so that it can create new facts.
There are three different types of rules:
Non Specific rules: Non Specific rules tell Rainbird under which condition(s) any subject instance relates to any object instance.
Figure 1: A non specific rule. Any person is eligible for any pass.
Subject or Object Specific: Subject or Object Specific rules tell Rainbird under which condition(s) any subject instance relates to a specific instance OR under which condition(s) a specific subject instance relates to any object instance.
Figure 2: An object specific rule, followed by a subject specific rule
Facts/Relationship Instances: Facts, or ‘relationship instances‘ tell Rainbird how a specific subject instance relates to a specific object instance – there are no conditions attached.
Figure 3: A fact between a person concept and an age concept – ‘person is age 61’
To demonstrate how to use the different types of rules, this article will show you how to build a map that uses the three types of rules to work out whether someone is eligible for a bus pass.
Non Specific rules are the most scalable type of rules. Non Specific rules are effectively broad statements about a relationship between concepts, and enable Rainbird to infer relationship instances for any subject and object instance concepts, rather than specific concept instances.
We will use Non Specific Rules in our example map to find out if a a person is eligible for a bus pass, depending on their age and occupation status.
Rules sit on relationships between concepts, so to start the map off, build the following concepts:
- 4 string concepts – ‘Person’, ‘Occupation Status’, ‘Pass’ and ‘Age Bracket’
- 1 number concept – ‘Age’ (the age will be input by the user at runtime)
Figure 4: Concepts and relationships for bus pass eligibility map
Next, create the following concept instances:
- Age Bracket – ‘Above 64’, ‘Below 65’ (the rule which will sort age into an age bracket will be built later in the article)
- Occupation Status – ‘Employed’, ‘Retired’
- Pass – ‘Bus Pass’ (for demo purposes, we will only create one pass concept instance)
Figure 5: Building the Non – Specific rule: (Person) is eligible for (Pass) under conditions
The rule tells Rainbird to return ‘That’s 3.50 for a single please!’ if a person is below 65 and employed, as the person will not be eligible for any pass.
The rule will be applicable to any person concept and any pass concept, and enables Rainbird to produce an outcome without having to know the age or occupation status of an individual before runtime.
Subject/Object specific rules, also referred to as ‘object-specific‘, ‘subject-specific‘ or ‘subject and object-specific‘ rules dependent on what part of the relationship is specified, use condition(s). Conditions tell Rainbird when a rule will be satisfied.
Subject/object specific rules are used when either a subject instance is linked to a specific object instance, a specific subject instance is linked to an object instance, or a specific subject instance is linked to a specific object instance, under a certain condition(s).
Object-specific rules are more scaleable than facts/relationship instances rules, because they can be applied to any subject instance, but they still only deal with specific object instances (the opposite is true for subject-specific rules)
Subject/object specific rules are often used when you are describing the circumstances for a specific fact to be produced, or if there is an anomaly within your data/’exception to the rule’ that isn’t accommodated by a Non-Specific Rule. They are also are used when you want a specific instance to be the outcome of a query/used in a fact created at runtime (e.g. in our example map, you may want an object-specific rule for bus passes, if the requirements for bus pass eligibility differ from other passes), and therefore don’t need a blanket rule that would be more appropriate for accommodating a large number of instances.
Continuing the Example build
Object specific rules are commonly used when building a number bracket, and when creating a rule that will provide a specific result if satisfied.
In our example map, to create the number bracket, open the ‘is in age bracket’ relationship, and add an object-specific rule for the ‘below 65’ instance. You will need to add the ‘%Person is age %age’ relationship as the first condition of the rule, as this condition will make Rainbird ask the user to input a number as their age. You will also need to add an expression to the rule, ‘%AGE is less than 65’. Once you have added the rule, you will also need to add another object specific rule for ‘above 64’. Follow the same steps, but change the expression to ‘%AGE is greater than 64’.
Now, Rainbird will create a ‘(Person) is in age bracket below 65’ fact if the subject of the query (any person) inputs a number less than 65 at runtime, or a ‘(Person) is in age bracket above 64’ if they enter a number greater than 64. The created fact will then be used by Rainbird to check whether a person is eligible for a bus pass.
Figure 6: Building the age bracket Object Specific Rules
You will also need to create an Object Specific rule so that Rainbird displays an outcome dependent on the result of the query.
Open the ‘is eligible for’ relationship and create an Object Specific rule for the ‘Bus Pass’ concept instance. For the conditions, add in the Object Specific ‘Person is in age bracket above 64’ relationship, as well as another Object Specific relationship, ‘Person has occupation status retired’. Now, Rainbird will know that a person is eligible for a bus pass, if they are older than 64 AND if they are retired:
Figure 7: Building the Object Specific Rule for the Bus Pass concept instance
You’ll notice that the rules you just created describe a specific set of conditions which do not accommodate instances other than those that are specified.
Relationship instances/facts tell Rainbird how two concept instances are linked and always will be linked, without being dependent upon anything else to be true. They are the least adaptable of all rules, as they only describe one specific relationship instance and therefore aren’t scalable.
To demonstrate the relationship instances/facts rule type, we will create a fact in the example map that will tell Rainbird information about a specific person (Pete).
Continuing the build example:
Due to Pete’s age of 70 and his occupation status ‘retired’ he will be eligible for a bus pass.
First, create a concept instance for ‘Pete’, under the ‘Person’ concept. If you open up the ‘Pete’ concept instance, you will be able to create facts between ‘Pete’ on the different relationships the ‘person’ concept is connected to:
Figure 8: Pete is 70, retired and eligible for a buss pass
Now, if we were to run the ‘is eligible for’ query, and enter ‘Pete’ as the subject, Rainbird will return the outcome ‘Bus Pass’ without needing to ask us about Pete’s age or occupation status, as Rainbird already knows this information as facts that between ‘Pete’ and the various other concepts exist inside the knowledge map.
Figure 9: Rainbird does not ask any questions as facts between ‘Pete’ and the other concepts in the map already exist
Note: A Rainbird knowledge map that only contains facts will act like a database, matching an instance given at run-time to any relevant facts that are stored in the map.
The RBLang below will generate the a map that uses the different rules mentioned in the article. Click on ‘Export .rbird’ to download the knowledge map, or ‘copy RBLang’ and paste the code directly into Rainbird.
Query and results
The non-specific rule sits on the ‘is eligible for’ relationship.
The object-specific rule also sits on the ‘is eligible for’ relationship.
For an example of a query using facts, run the ‘is eligible for query’and enter ‘Pete’ as your subject.
