Library: Sub 3 – “Elbow” – Object specific Rules
Object-specific rules are used to provide results for specific situations
This Build Structure has its name from the structure, where two concepts are connected to a central concept, but not to each other – looking like an arm/elbow.
Intent
Object specific rules address situations where a specific answer is required for set situations.
Reducing the number of relationships makes a map easier to visualise, with fewer cross-connecting relationships.
They can be used alongside inference rules (see ‘Building in Triangles) to provide speedy query results, rather than having to go through a full set of questions for the same result.
Applicability
When can this pattern be applied?
- When dealing with a limited number of possible concept instances on both the ‘origin’ and ‘query’ concepts.
- When working with string and/or True/False (boolean) concepts
- When working with strings instances that have ‘set’ data where the facts are highly unlikely to change (as they are built into the map rules)
Limitations
By their very nature, object-specific rules only cover the specific cases addressed in the rule. This raises the risk of a logic gap which will cause the query to either fail or provide an incomplete answer, especially if there is not also a corresponding inference rule . For this reason this structure should only be used when:
- There is a specific, limited list of possible facts in both the origin relationship and in the queries relationship.
- The facts in the origin relationship and possible facts in the query relationship are not expected to change often (as the Rainbird map will need to be updated to reflect this)
You will need to build a rule for every concept instance. This means that is usually becomes more efficient to build a triangle structure for more than a few concept instances (generally 2-4).
Note: Do not use the Elbow technique with a plural relationship between any two instances OR when working with number/date concepts (see Comparative Expressions)
Otherwise, consider whether an inference rule would be more flexible (see Building in Triangles).
The following example decides whether or not a device is safe, depending on whether or not it is plugged in.
Figure 1: Generic Structure of the ‘Elbow Technique’
Motivation
Both “Plugged in?” and “Safety status” are string concepts. They could also easily be True/False (Boolean) concepts.
This example has a limited number of possible origin instances (the device is either plugged in or not), and query instances (the device is either safe or not).
These are the only possible instances that can exist for “Plugged in?” and “Safety Status”, i.e. the map will likely never need to be updated to reflect a revised set of circumstances.
Follow these steps to recreate the build pattern example:
Create three string concepts:
- Device
- Plugged In?
- Safety Status.
Create the following relationships:
- Device is plugged in?
- Device has safety status
Figure 2: Creating Concepts and Relationship
Create instances
Create two instances of Plugged In?:
- Yes
- No
Create two instances of Safety Status:
- The device is safe
- The device is not safe – do not tamper with it!
Figure 3: Creating Instances
On the is plugged in relationship set the Question Configuration to Second Form (object) only, and the question wording to Is the (Device) plugged in? Change Add Instances to None.
Figure 3: Changing the question wording
On the has safety status relationship set the Question Configuration to None
When adding a new Rule, we can select the Instance of the Concept Safety Status. This will create create an Object Specific Rule
Figure 4: Creating the Object Specific Rule
We want Rainbird to point to those Instances under the Conditions if the device has been plugged in or not, when answering the relationship has safety status.
Where create the following two rules:
First rule Object – %DEVICE has safety status “The device is safe”:
On conditions that:
To cover the second possible selection, we need a create a second new Rule:
Second rule Object – %DEVICE has safety status “The device is not safe – do not tamper with it”:
On conditions that:
Query and Results
The main query is built on the rule ‘has safety status’. The outcome of the query will be the Object we defined.
