Match Group Elements - Description and Configuration

You must understand match group elements to define correct match rules.

The following topics provide information about each element within a match group that includes information about how to configure them.

URI, Label Element

uri

Example - configuration/entityTypes/Individual/matchGroups/Rule1

Note: Ensure this is unique across your match groups.

label

Provide a meaningful label. It will be displayed in the Hub as a summary description of the purpose of this rule.

Type Element

Each match group is designated by you to be one of four types: automatic, suspect, <custom>, and relevance_based described below. The type you select governs whether you will develop a boolean expression for your comparison rule or an arithmetic expression. The types are described below.

Behavior of the automatic type

With this setting for type, the comparison formula is purely boolean and if it evaluates to TRUE, the match group will issue a directive of merge which, unless overridden through precedence, will cause the candidate pair to merge.

Behavior of the suspect type

With this setting for type, the comparison formula is purely boolean and if it evaluates to TRUE, the match group will issue a directive of queue for review which, unless overridden through precedence, will cause the candidate pair to appear in the “Potential Matches View” of the MDM UI.

Behavior of the <custom> rule type

The custom rule type is provided to give you the ability to invent your own rule type with its own name and granular control of the actions it takes. (Names of ‘suspect’, ‘automatic’ and ‘relevance_based’ are not allowed since they are already used by the system) The custom rule’s comparison formula will be boolean and identical in concept to the ‘suspect’ and ‘automatic’ types but you will be able to define the “matchActions” that occur if the rule formula evaluates to TRUE. For more details, see section, “Explanation and configuration of the “custom Rule type”

Behavior of the relevance_based type

Unlike the preceding rules, all of which are based on a boolean construction of the rule formula, the relevance-based type expects you to define an arithmetic scoring algorithm. The range of the match score determines whether to merge records automatically or create potential matches. For more information, see Relevance-Based Matching - Detailed Explanation.

The rule types and their ability to issue directives to the match engine are as follows:

Table 1. Rule Type Directives
Rule Type	Rule Formula	Can issue a directive of "merge"	Can issue a directive of "queue for review"	Can publish an event of "auto link"	Can publish an event of "potential link"
`automatic`	boolean	Yes	No	No	No
`suspect`	boolean	No	Yes	No	No
`<your rule name`	boolean	Yes	Yes	Yes	Yes
`relevance_based`	arithmetic	Yes	Yes	Yes	Yes

Precedence of directives, and the Negative Rule

A merge directive from any rule supersedes a queue for review directive from any other rule.
If a negativeRule exists in the matchGroups and it evaluates to true, any merge directives from the other rules are demoted to queue for review. Thus, in that circumstance, no automatic merges will occur. (Note: While supported, the actual use of a negativeRule is not encouraged because it affects all the other rules. So use wisely. (see section Using a Negative Rule)

Scope and useOvOnly Elements

Scope

Optional: Yes; Default is ALL

The Scope parameter of a match group defines whether the rule should be used for Internal Matching or External Matching or both. External matching occurs in a non-invasive manner and the results of the match job are written to an output file for you to review. Values for Scope are:

ALL - Match group is enabled for internal and external matching (Default setting)
NONE - Matching is disabled for the match group
INTERNAL - Match group is enabled for matching records within the tenant only
EXTERNAL - Match group is enabled only for matching of records from an external file to records within the tenant. External matching is supported programmatically via the External Match API. The functionality is also available through the External Match Application found within the Reltio Console.

Note: All scopes are available for the _verifyMatches endpoint.

useOvOnly

Optional: Yes (but strongly recommended); Defaults to false.

If set to true, then only the OV of each attribute will be used for tokenization and for comparisons. For example, if the First Name attribute contains “Bill”, “William”, “Billy”, but “William” is the OV, then only “William” will be considered by the cleanse, token, and comparator classes.

DocumentComparator, matchServiceClass Elements

DocumentComparator

Optional: No

Specify as

{ "class": "com.reltio.match.comparator.AlwaysDocumentComparator", "parameters": [ { "parameter": "ALWAYS_TRUE", "value": "true" } ]}

matchServiceClass