Rainbird uses three different ways to get information. Rainbird will:
Match:
Rainbird will consider and try to match concept instances and facts created by the knowledge engineer and inserted directly into the knowledge map, or by the end-user at run time. Populating a map with concept instances and facts provides Rainbird with direct access to the data required to solve a query. Setting a knowledge map up to match concept instances and facts is straightforward and easy to track; however it’s not very flexible and cannot cover every potential subject/object variable as they would need to all be manually input by the engineer/end-user.
Infer:
Thanks to the rules enclosed in relationships, Rainbird can infer information. Rainbird will attempt to satisfy the conditions of a rule by generating appropriate relationship instances at run-time by running any rules that are provided for the relationship in question. Rainbird will generally infer a final decision, but Rainbird will also infer information needed for the final decision. Setting up Rainbird to complete a query through inferring information is a suitable method to cover all potential subject/object variables.
Ask:
If Rainbird cannot match or infer a relationship instance, Rainbird will ask questions to the user. If the user provides an answer, a new relationship instances will be created which Rainbird can use to satisfy the rules of a condition. A query just relying on Rainbird asking questions can be time consuming for users to complete, especially when the questions pertain to general truths, which could potentially be asked again and again.
A concept instance is a specific example of a concept. “Someone” is a general concept; an instance of ‘someone’ could be a particular person, “Paul”.
Figure 1: ‘Someone’ concept with concept instance ‘Paul’
A fact (also called a relationship instance) is for relationships what a concept instance is to a concept. It is a particular example of a relationship. For example, a general relationship could be ‘has date of birth’, with both “Someone” and “Date of Birth” being concepts. A fact, or relationship instance, of this relationship could be “Paul has date of birth 1961-06-14”.
Figure 2: Creating the fact (relationship instance) ‘Paul has date of birth 1961-06-14’
Each fact has a certainty factor (CF), determining how sure we are about that fact being true. By default, the CF is set to 100%. However, we can lower the CF. For example, if we were making an assumption about Paul’s date of birth by sight, we would be less certain than asking Paul directly as we would be less sure that our assumption was true. We could change the certainty on a fact “Paul has date of birth 1961-06-14″, from 100% to a Certainty Factor of 65%.
Figure 3: The certainty factor of the fact ‘Paul has date of birth 1961-06-14’ is now 65%
There’s no unit of measurement associated with CF. CF can represent whatever Rainbird designers want (probabilities, subjective scale, risk score, etc). However it is expressed in percentages, between 1% and 100%. Rainbird will not create facts if the certainty is 0%
CFs are only associated with facts, not instances. The CF of an outcome to a query is not the CF of the final outcome instance, it is the overall CF of the query, composed of the main input (e.g the first instance, ID given to Rainbird), linked with an outcome (i.e. the result instance given by Rainbird), by a relationship (the one used for the query).
The example map below determines if a person is mortal or immortal. We interrogated an ancient Greek theologian to understand the subtleties of Olympians, humans and mortality.
The map will demonstrate the key differences between the 3 main ways Rainbird can be fed concept instances and facts, as well as going through the different types of facts that exists.
To understand who’s mortal or not, we first build the concepts and relationships in a triangle as shown below:
Figure 4: Basic triangle Someone-Entity-Mortality
The concept on the right “Strict Mortality” is a boolean (true/false) concept, as for the purposes of the model, someone is either Mortal or Immortal.
Overall Rule:
The relationship called “is strictly mortal or not” is the relationship that will be queried. We create the following rules to enable Rainbird to make an inference:
Figure 5: “is strictly mortal or not” relationship settings
As no facts have been created (except some question word tweaking), here’s how the model will behave:
Figure 6: first stage model behaviour
Currently, Rainbird asks whether humans are mortal. It is safe to say that all human beings are mortal, hence we can store this information directly in the knowledge map. On the inverse, for the example, we assume that all Olympians are immortal. Now, Rainbird will not ask this question anymore, which will improve the user experience as the user will not have to answer redundant questions.
To create this fact, we need to create our concept instances and facts as shown in the figure below:
Figure 7: Creation of facts concept instance and facts
The question has been turned off by setting the ‘entity has strict mortality’ relationship question configuration setting to ‘none’. Now the model will not ask whether a human is mortal or an Olympian is immortal, as Rainbird already knows the answer to these questions.
Here is how the model behaves:
- Query the relationship “is strictly mortal or not” and input “Someone” as the name
- Rainbird asks a question about the relationship “has entity” which will determine “Someone’s Entity”
- Rainbird crawls the information already programmed in the map (facts) on the “entity has strict mortality” to know what entities are Mortal or not.
- Rainbird infers an answer thanks to the rules enclosed in the “is strictly mortal or not” relationship, and the previous information gathered.
Different Concept Types, as well as mutually exclusive concepts, in both singular and plural relationships, can be used in facts.
Because the concept “Strict Mortality” is a boolean concept, the outcome of the model will display like this:
Figure 8: Boolean result
The outcome provides little useful information to the end-user. We’d rather have something like “Socrates is Mortal”, or just “Mortal”. To improve the model, we’ll use the mutually exclusive type concept.
Figure 9: Knowledge map with a new mutually exclusive concept
We now have created the new “Strictly Mortal 2” concept and the associated relationships. We have toggled the mutually exclusive button in the concept menu (see figure 10) to on. New facts needed to embody the general truth that “Olympians are Immortal” and “Humans are Mortal” are created by opening the Entity concept and selecting the appropriate concept instance for each.
As the ‘Strictly Mortal 2’ concept is mutually exclusive, two concept instances need to be created. Otherwise you can’t create facts for the ‘entity’ concept instances:
Figure 10: impossibility to create facts without concept instances at both ends of the relationship
Hence we create two instances in the “Strict Mortality 2” concept:
Figure 11: settings of the Strict Mortality 2 concept
After creating the concept instances, then the facts based on these new “Strict Mortality 2” concept instances, we can create the rules that will enable the logic of the map to work. As for the “is strictly mortal or not” relationship (see figure 5), we create rules in the “is strictly mortal or not 2” relationship for the new concept and relationships.
Here is how the final outcome looks like now:
Figure 12: explicit outcome thanks to mutually exclusive concept
Now our expert in ancient greek theology tells us children between Olympians and humans exist. “They are 50% Mortal and 50% Immortal, it’s complicated” he says.
We now need to adapt our model so it can give plural outcomes (mortal and immortal at the same time). For that we need a plural relationship. Neither boolean or mutually exclusive concepts can be plural, so we create a third concept simply called “Mortality”, since this time, we assume someone can be both Mortal and Immortal at the same time.
Here is the new model:
Figure 13: Mortal Model with a third Mortality concept
We create the rule in the “is mortal or not relationship”, as we did in the previous steps (see figure 5).
We create the Concepts instances “Mortal” and “Immortal” in the “Mortality” concept.
We create the facts for the relationship “entity has mortality”, with the concepts instances “Human” and “Olympians”.
Now we create a new concept instance called “child of Olympian and human” in the “Entity” concept. We also create a fact for this concept, this time we want the fact to reflect that Hercules is 50% Mortal, and 50% Immortal.
Hence it requires:
- To attach two objects to a single object, which is only possible if the relationship is plural
- To change the Certainty Factor for the ‘child of Olympian and human’ fact
Here’s how it looks like:
Figure 14: entity has mortality settings
The relationship “is mortal or not” has to be set to “plural”, otherwise the outcome of the query will be singular.
Figure 15: Creating the plural facts and changing the Certainty Factors
Here’s what the outcome of the model will now be:
Figure 16: Plural outcome with Certainty Factors
Date concepts can also have facts associated with them. It is well known that no Olympians have been born in modern times. The model needs to be configured so it infers that people born after 1900 are mortals.
Here’s what it would look like if we applied the same structure and logic as for the previous examples:
Figure 17: unscalable date fact
Now, Rainbird will be able to infer that a person is mortal if they are born on the 1st of January 2000, and only for this date. If we want to cover all the years of the 20th and 21st century, we would need to create a lot of facts. This is obviously not scalable.
We would need to change the logic to scale the model. To do so we could create time period groups in which a person will fall under depending on his date of birth. Here’s an example of such concept instances groups:
Figure 18: Time period instances
On top of the ‘date of birth group’ concept, we would need to create:
- A relationship between “Mortality” and “Date of birth group”, with a fact that says “Mortal can be inferred if the birth group is Born in between 1900 and 2100” (“Mortal” pointing to “Born in between 1900 and 2100”).
- A relationship between “Someone” and “Date of birth group”, with questions set to “on”.
- A relationship between “Someone” and “Mortality”, with a rule as described in figure 5 using the two new relationships we created (“has date of birth group“ and “can be inferred with date of birth group” in the knowledge map).
Querying the relationship we just created between “Someone” and “Date of birth group” (called “is mortal based on date of birth group”) will give us the outcome mortal if we say that “Someone” is in the birth group “Born in between 1900 and 2100”.
This solution is scalable and doesn’t actually use Date facts to work. Date facts are more appropriate to input in a map to work out the birthdate of the person by creating an instance in the “Someone” concept and creating a fact based on a “Someone” concept instance:
Figure 19: Someone fact
Note: this type of structure will require the end-user to specify the exact person instance when starting a query with the “Someone” Concept as a subject.
Number concept can also work with facts. Based on theological statistics, we know that Mortal people have an average life expectancy of 80 years while Olympians have one of 1 000 000 years (based on a controversial thesis about the end of the world).
Let’s use this knowledge to create rules to enable the model to predict the potential date of death of someone depending on if they are Mortal or Immortal, or a mix of both.
To do so, we need to create a “Life expectancy” concept and create a ‘number fact’ to represent this knowledge:
Figure 19: Number fact creation
Now we need to create the rules which use this fact, and other data, to infer an estimated date of death. As this part of the model is out of the scope of this article, the explanation on how to create it will be skipped. However the RBLang at the end of the article contains this feature if you wish to have a look at how it has been made. It uses the certainty factor of the previous facts to estimate a date which will be between 80 and 1 000 000. The figure below shows the result of a query:
Figure 20: Estimated date of death
Note: data can also be fed to Rainbird through data sources or injection (see importing knowledge from google spreadsheet).
For more information on concepts, click here to watch a Rainbird training video about them.
The RBLang below will generate the example map used 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
- For the Boolean fact, query the “is strictly mortal or not” relationship.
- For the Mutually exclusive fact, query the “is strictly mortal or not 2” relationship.
- For the Plural answer fact, query the “is mortal or not” relationship.
- For the dates facts, the unscalable solution is run by querying the “is mortal based on date” relationship, and the scalable solution is run by querying the “is mortal based on date of birth group“ relationship.
- For the Numbers facts, query the “has estimate date of arrival” relationship.
