Relationships – Inferring Reference Relationships

We’re on to part four of our learning journey, covering functional items that are often a challenge to rule authors in Oracle Policy Modeling. This week we are looking at Inferring Reference Relationships and how this whole concept of relationships defined by rules can benefit your rule designs.

Before we get started, if you are looking for the previous parts of this journey here they are:

Part One : Containment Relationships

Part Two : Inferring Containment Relationships

Part Three : Reference Relationships

For our examples this week we will be Inferring Reference Relationships using the following example project, which was used in the previous article. We have a car sharing model with people and vehicles. Last time out we discovered the use of reference relationships to manually let the user of the interview decide who goes in which vehicle, subject to our restrictions (1 person in a car, multiple people in a car, multiple people in multiple cars and so on).

Let’s take the following situation. Our car sharing company is working well and we need to implement some more business logic. We want to highlight automatically, potential drivers of each vehicle.

There are different ways to achieve this, but for our example we will use a reference relationship.

Suppose we want to be able to identify people by the following criteria: the vehicle must be a standard one, and the person must have a standard driver’s license. And of course, the person must be selected as a potential driver of the vehicle they want to travel in. If you are happy sitting in vehicle one, then you cannot be a potential driver of vehicle two!

So let’s create a relationship called “the potential drivers of the vehicle”

Inferring Reference Relationships - New Relationship

Inferring Reference Relationships

Now we can infer membership of this relationship – in other words, we can write a rule that defines which drivers are considered to be potential drivers of their chosen vehicle. This reference relationship can be inferred in a rule:

Inferring Reference Relationships - Rule in Word

The use of is a member of or IsMemberOf() is how you can define the rules to allow certain instances to become members of this relationship. So if you are sitting in Vehicle 1, you have a standard driving license and the vehicle is a standard one, then you are a potential driver. Notice how in the rule above, the is a member of can operate both as a membership conclusion and as a membership statement or condition. So we can make sure our logic is applied to the vehicle they chose (the reference relationship we created in the previous article) and not to any other vehicle.

We can extend the rules to cover non-standard vehicles and add a variety of extra attributes to leverage the membership concept for our demonstration of Inferring Reference Relationships:

Not only do we now handle non-standard vehicles but we can also set a boolean attribute on the person to indicate if they have been flagged as a potential driver. Finally we can leverage our reference relationships to do standard things like InstanceCount(). Inferring Reference Relationships can help organize our data model and writing an inferred relationship rule is the way to do this. Once we have inferred the membership, the relationship can be counted, referred to, and treated as you would any other relationship.

Inferring Reference Relationships - Interview

Or we can go one step further and add some images instead :


To summarize what you have seen in this step on the learning journey, consider the following. In your project you have two reference relationships. One is inferred (the potential driver…) and the other is entered by the user (the person’s choice of vehicle). Both are defined in the same way in Oracle Policy Modeling.

The only difference is that one is defined on a Screen with a Relationship Control, the other is defined in a Word document with instructions to Oracle Intelligent Advisor on how to do it. A reference relationship can be inferred or entered by the user, but it cannot be both. Inferring relationships in this way can facilitate making calculations (how many potential drivers do we have in this car?) as well as leading to further decisions (if a vehicle has no potential driver then the car share isn’t really working very well!) and lots of other things along the way.

It can feel hard at first to understand this sort of concept. But if you are not creating a vehicle or a person,but you are establishing some sort of connection between them, then you are looking at a relationship.

And here is a little walk-through of the project. If you would like a copy, please drop a note in the comments.


Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Intelligent Advisor IT Consulting Serving Customers Worldwide
Hide picture