Inheritance in OPA data model

Question

Hi all,
I have a problem which OPM does not seem to handle well, but maybe I am lacking knowledge concerning some functionality. I am using a client patched 10.1 version of OPM.
Situation:
- I have an attribute in Global, which states the possibility to export an entitlement. This attribute is deducted using multiple compositions of conditions on both "child" level and "applicant" level. These are both entities in my data model.
- However, some of the conditions are the generic for both roles. Therefore, what I really want to do is check attributes on "person" level and relate these to "the child" and to "the applicant".
- Now, I've created an entity "the person" with a relation to "the child" and a relation to "the applicant".
This raises an issue with the For/ForAll operator
Issue:
- To use the "For" operator, a -to-one relationship is needed. However, I can have two persons of which one is a child and one is an applicant. So, I need a - to-many relationship for person (from Global)
- If I use the "ForAll" operator to 'work around' this problem, the goal attribute will stay inconclusive as the relationship from person 1 to the child is known, but from person 2 to the child in unknown (and vice versa for the applicant)
Question:
It seems to me that this is an issue of inheritance which OPM cannot handle. I am wondering:
- has anyone dealt with this problem and/or does anyone have a solution?
- is it likely that the entity containment functionality of OPM 10.2 + will be able to solve my issue?
Thanks & regards, Els

Answer 1

Given that I don’t know the details of your source material, and I don’t know Dutch, perhaps the best option is if I show you how to get a simple inferred relationship set up and working. Hopefully then you’ll see what it’s doing and know how to set it up for your own rulebase.
1. Create a new empty test rulebase.
2. Add a Properties file. Add a regular one-to-many containment relationship from Global to ‘the person’.
3. From within the Properties file, have Global selected and in the right hand pane select the Relationships tab.
4. Right-click in an empty space in the right hand pane and select ‘New Relationship’. Use these settings:
- Source: Global (This will already be set, and will be read-only. If it isn’t already set to Global, then you didn’t do Step 3.)
- Target: the person
- Relationship type: Inferred (many-to-many)
- Text: the adults
5. Save the Properties file.
6. Create a Word rule doc.
7. Add a membership rule for the inferred relationship. A membership rule specifies the logic used to decide which instances are members of the inferred relationship. The parts in italics below are just examples of what the red configuration text will look like when the rule is compiled.
+[IsMemberOf(“person”,adults)]+ the person is a member of the adults if
+[p1 >= 18]+ the person's age >= 18
In my example, I’m just basing it on age. It could be based on just about anything. Try to name your inferred relationship appropriately. I called it “the adults” since that’s what the group is. If I needed to have a group of people >= 18 years and who are female, then I’d call it something like ‘the female adults’, and obviously I’d include gender in the membership rule.
8. Add some simple entity calculation rule such as these:
the number of adults in the group = InstanceCount(the adults)
the total amount of savings of the adults in the group = InstanceSum(the adults, the person's savings amount)
9. Build and Debug. Work in the Data tab, not the OWD tab. You’ll be able to see more detail about what’s going on if in the Data tab.
10. Add three instances of ‘the person’. Make two people older than 18 years, and one person younger than 18 years. Give each of them a different savings amount.
11. Look at the Global results and you will see that the InstanceCount rule calculated ‘2’ and the InstanceSum rule only added up the savings from the subset of people who are adults.
My general advice on this is:
If the logic you need to do over subsets of entity instances is relatively simple, and can be easily accommodated by existing Instance functions, then don't bother with inferred relationships. Just set up the regular containment relationship and use the existing entity functions. Here are few examples of less complex entity calculations which can easily be handled without inferred relationships:
- count the number of adults
- calculate the total income of all household members who are over 25 years
- find the age of the youngest male child
So my example rulebase above is actually one for which I wouldn’t use inferred relationships if that was all I needed it for. I just wanted to pick a simple example to explain the concept. To do the example above without inferred relationships, you’d just need to use InstanceCountIf and InstanceSumIf and put the conditional logic in each calculation rule.
If the logic you need to do over subsets of entity instances is much more complex and either it's not possible without inferred relationships, or it's just easier/more concise with inferred relationships, then add inferred relationships.
Cheers,
Jasmine