Write rules that infer relationships and entities

Rules that infer relationships and entities can be useful for grouping entity instances in order to refer to the group as a whole in your rules and use the standard entity functions in a more powerful way. For example, you could:

Collect payments and write rules to sum all payments made within the same year
Determine eligibility for benefits and write rules to sum all eligible benefits or create a payment plan for all eligible benefits
Collect product information and write rules to determine which services should be created based on the customer’s product

Further examples are provided under Worked Examples below.

What do you want to do?

Infer membership of a relationship

Infer existence of entities to satisfy the relationship

See worked examples

Infer membership of a relationship

The syntax to use to infer that existing entity instances are members of a relationship is:

<target entity> is a member of <relationship text> if
IsMemberOf(<target entity>, <relationship text>) if

Note that membership rules must be written in the positive form. That is, it is not possible to infer that an entity is not a member of a relationship.

All subsequent rule levels for this conclusion must have the source entity and the target entity in its reasoning scope. The relationship used must be defined as a many-to-many relationship type in the properties file for the project. (See Define a relationship for more information.)

In the example rule below, a membership statement is used to conclude membership of the inferred relationship 'the parent’s school-aged children'.

the child is a member of the parent’s school-aged children if

the child is of school age

Notes /Limitations

A relationship conclusion can only ever be the top line of a rule. If the syntax is used anywhere else in a rule, then it will be treated as a membership statement (see Use relationship membership as a rule input).
An inferred relationship will be partially known if the rule used to infer it returns unknown for any of the potential target entity instances.
An inferred relationship will be partially known if its target entity is not complete.
Combining manually created relationships with inferred relationships is not allowed.
Combining inferred relationships with temporal values is not supported.
A relationship must only be inferred in its primary direction.

Infer existence of entities to satisfy the relationship

You can also write a rule that creates entity instances to become members of a relationship.

The syntax to use to infer that entity instances should be created (or deleted) as members of a relationship is:

<relationship> (<identifying value>) exists if
InferInstance(<relationship>,<identifying value>) if

or in table form (where multiple instances are needed):

Relationship
<identifying value>	Condition
<identifying value>	Condition

The identifying value can either be a fixed value ("spouse") or a variable (the tax year) which is then used as the identifying attribute for the entity instances created.

At runtime, the engine will evaluate each rule in the above form, evaluate the condition(s) and will create an instance for any condition that is true, and destroy any instance for which no condition returns true.

For example, assuming you have the following data model:

Example 1: Creating a single instance

Writing the rule:

the locations ("Main office") exists

will create a single instance of the entity "the location" which is a member of the containment relationship "the locations". The instance will have "Main office" as the value of the identifying attribute.

Example 2: Creating multiple instances using a rule table

Writing the rule:

the locations
"Main office"	the assessment date >= 2009-10-01
"Warehouse"	the assessment date >= 2000-01-15
"Factory"	the assessment date >= 2000-01-15

will create instances of the entity "the location" (depending on the assessment date), which are members of the containment relationship "the locations". These instances will have "Main office", "Warehouse" and "Factory" as the value of their identifying attributes.

Example 3: Creating multiple instances from a single entity level-attribute

Writing the rule:

the location in which the employee works (the employee’s local office) exists

will create an instance of the location entity for each unique value of "the employee’s local office". These instances will be members of the relationship "the location in which the employee works" and have the value of the employee’s local office as the value of the identifying attribute.

Notes /Limitations

Combining manually created instances with inferred instances is not allowed.
Combining inferred entity instances with temporal values is not supported.
Only a single attribute of the entity instance can be inferred as a part of the entity rule. For example, the type of benefit ("unemployment benefit") can be set but the amount of the benefit would have to be set via a separate rule.
Inferred entity instances may not contain base level attributes.
A relationship that participates in an inferred entity instance rule is considered to be an inferred relationship. This means that an inferred relationship rule cannot be used to prove the same relationship used in an inferred entity instance rule.

See worked examples

The following example rulebases installed with Oracle Policy Modeling demonstrate the inferred entity instance functionality. For how to view these rulebases, see Open an example rulebase.

Inferred Brand Discount rulebase
This rulebase models a generic purchase order scenario using inferred entity instances to group order items by brand and then apply a brand discount for purchases over $100 for any given brand.
Inferred Benefits rulebase
This rulebase infers the existence of benefits and tallies the number of people eligible for each benefit. It also demonstrates inferred instances using rule tables.
Inferred Tax Years rulebase
This rulebase infers the existence of tax year entity instances so that further rules related to those tax years can be applied. This can be helpful if you want to ask further information about previous years (ie "did you submit a tax return for <tax year>") but only ask about tax years relevant to the interview, without pre-populating every possible tax year.
Inferred Service Delta rulebase
This rulebase infers the existence of service entity instances in order to identify which services should be started, stopped or retained when a customer changes phone plans. It also demonstrates inferred instances from global values.