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
configuration/entityTypes/Individual/matchGroups/Rule1label
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 Configuring relevance-based matching rules.
The rule types and their ability to issue directives to the match engine are as follows:
| 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 |
- 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 groupINTERNAL- Match group is enabled for matching records within the tenant onlyEXTERNAL- 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.
_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
{ "class": "com.reltio.match.comparator.AlwaysDocumentComparator", "parameters": [ { "parameter": "ALWAYS_TRUE", "value": "true" } ]}matchServiceClass
Optional: No
com.reltio.businesslogic.match.providers.internal.InternalMatchServiceOverrides Element
The overrides element lets a match group reference the attribute names that a match method expects. The match service then reads the actual values from the attributes that exist in your tenant's data model.
Without the overrides element, every attribute reference in the match group resolves directly against the data model, with no mapping applied. When present, the mapping is resolved consistently for every match group element that references an attribute: operands, cleansers, match token classes, comparator classes, and the document tokenizer.
attributesMapping
attributesMapping is a list of mapping entries, declared under overrides.attributesMapping. Each entry contains the following two fields.
| Field | Required | Description |
|---|---|---|
matchMethodAttribute | Yes | The attribute name used inside the match group definition. It does not have to exist in the tenant's data model, it can be a purely logical (virtual) attribute. |
dataModelAttribute | Yes | The attribute in your tenant's data model that holds the actual values. Must refer to an attribute that exists in the tenant's data model. |
Supported reference formats
Both matchMethodAttribute and dataModelAttribute accept any of the following three equivalent formats.
| Format | Example |
|---|---|
| Full URI | configuration/entityTypes/Individual/attributes/Identifiers/attributes/ID |
Relative path, / separator | Identifiers/ID |
Single-attribute mapping
The following mapping resolves the method-facing name Name to the tenant's OrganizationName attribute.
{
"overrides": {
"attributesMapping": [
{
"dataModelAttribute": "OrganizationName",
"matchMethodAttribute": "Name"
}
]
}
}
The match group elements are then written using the matchMethodAttribute name. In the following fragment, an exact operand references Name in full-URI form; the mapping above resolves it to OrganizationName at match time.
{
"rule": {
"and": {
"exact": [
"configuration/entityTypes/Organization/attributes/Name"
]
}
}
}
Validation rules
Reltio validates the mapping when you save the configuration:
-
Names, paths, and URIs may contain letters, numbers, slash (
/) only. -
dataModelAttributemust refer to an attribute that exists in the tenant's data model.matchMethodAttributeis not required to exist in the data model, which is what allows it to be a virtual attribute.
An invalid mapping is rejected at configuration time, so a typo or a reference to a non-existent tenant attribute is caught before it can affect matching.
Cross-attribute matching
Cross-attribute matching maps more than one dataModelAttribute to the same matchMethodAttribute, so the logical attribute aggregates the values of all mapped tenant attributes. The following match group matches an organization when its name equals the other profile's "doing business as" name, and vice versa. Both OrganizationName and DoingBusinessAsName map onto one logical attribute, AnyOrganizationName, which does not exist in the data model — it is defined only by the mapping.
{
"uri": "configuration/entityTypes/Organization/matchGroups/CrossOrganizationName",
"label": "Organization name matches DBA name",
"type": "suspect",
"scope": "ALL",
"useOvOnly": "true",
"rule": {
"and": {
"exact": [
"configuration/entityTypes/Organization/attributes/AnyOrganizationName"
]
},
"matchTokenClasses": {
"mapping": [
{
"attribute": "configuration/entityTypes/Organization/attributes/AnyOrganizationName",
"class": "<match-token-class-selected-for-this-rule>"
}
]
},
"comparatorClasses": {
"mapping": [
{
"attribute": "configuration/entityTypes/Organization/attributes/AnyOrganizationName",
"class": "<comparator-class-selected-for-this-rule>"
}
]
}
},
"overrides": {
"attributesMapping": [
{
"dataModelAttribute": "OrganizationName",
"matchMethodAttribute": "AnyOrganizationName"
},
{
"dataModelAttribute": "DoingBusinessAsName",
"matchMethodAttribute": "AnyOrganizationName"
}
]
}
}
Because AnyOrganizationName aggregates the values of both attributes, a match is found when either attribute of one entity shares a value with either attribute of the other entity; for example, entity A's OrganizationName equal to entity B's DoingBusinessAsName.
For more information, see Configuring relevance-based matching rules and Comparator Classes.