Reltio attribute types

Learn about the unique Reltio attributes for entity types.

Reltio multi-domain MDM makes defining your data model simple and intuitive. We provide four attribute types to define attributes, relationships, and interactions for your entity types.

simple
nested
reference
analytic

These attribute types enable you to:

Build a logical data model (rather than relying on physical tables and foreign keys)
Define entity, relationship, and interaction types granularly.
Provide detailed data to content and interaction designers.
Offer business users rich and streamlined, search and navigation experiences.

Simple attribute type

The Simple attribute type represents a single characteristic of an entity, relationship, or interaction. It's the only manifestation of the attribute type in Reltio multi-domain MDM that you must define as a data type. The nested, reference and analytic attribute types represent combinations or collections of simple subattribute types.

Simple attribute type definitions: Let's look at this list of available data types for defining the Simple attribute type.


Simple attribute's data type	Description	Supported Format	Additional Information
String	Can be any text.		Software limits the length of the value by the maxAttributeValueSize parameter in the physical configuration, where the default length is 10240 characters.
Int, Integer, Long, Dollar	Reltio platform considers all these types as Long java type. Values of these data types are indexed as 64-bit integer numbers in the search engine with the following values: A minimum value of -2^63 A maximum value of +2^63
Float, Double, Number	Can be any value that can be parsed to the Double java object (Double.parseDouble(value). The software indexes the values of these data types as 32-bit floating-point numbers in the search engine. Note: If you want to store integer values in Float, Double, and Number data types, note the following important points: A minimum integer value is -16777217 A maximum integer value is +16777217 Storage of values outside the range mentioned above results in loss of precision and unexpected search results.
Boolean	Can be any value that can be parsed to the Boolean java object (Boolean.parseBoolean(value) .	Possible values considered as true or false.	Look at the possible values for Java type Boolean (java/lang/Boolean.java).
Date, Time, Timestamp	Software uses Date to capture calendar date information in multiple formats.	Supported Date formats: yyyy-MM-dd MM/dd/yyyy MM.dd.yyyy MM-dd-yyyy yyyy/MM/dd yyyy-MM-dd yyyy.MM.dd yyyyMMdd	Supports the Time format but does not consider extra information, such as hours and minutes.
Date, Time, Timestamp	Time and Timestamp are the same types.	Supported formats for Time and Timestamp : yyyy-MM-dd'T'HH:mm:ss.SSSZ yyyy-MM-dd’T'HH:mm:ssZZ yyyy-MM-dd’T'HH:mm:ss.SSSZZ MM/dd/yyyy HH.mm MM.dd.yyyy HH.mm MM-dd-YYYY HH.mm	Supports the Date format but the missing information, such as hours and minutes are filled in by zeros. Date-time format pattern: "yyyy": Year with four digits "MM": Month with two digits (01-12) "dd": Day of the month with two digits (01-31) "T": Separator indicating the beginning of the time portion "HH": Hour of the day in 24-hour format with two digits (00-23) "mm": Minutes with two digits (00-59) "ss": Seconds with two digits (00-59) "SSS": Milliseconds with three digits "Z": Indicates the time is in UTC, and it's also a separator "ZZ": Time zone offset, where "ZZ" represents the time zone, e.g., "+hh:mm" or "-hh:mm". The presence of "ZZ" at the end indicates the inclusion of the time zone information.
Blob	This type of attribute stores multiline text data.		Allows entering any text in a blob. Doesn't allow the use of the same text for searching as the value represents binary data.
URL, Blog URL, Image URL	Can be any text and displays as a link on the Hub.		Allows text wrapping, if needed.

Nested attribute type

You can use the Nested attribute type to create collections of simple attributes by nesting them. The nested attribute helps you streamline your UI.

Let’s look at an example of a phone number that is a Nested attribute. You break the phone number down by using nested subattributes. The typical subattributes of a phone number include:

Number
Type
Area code
Extension

Continuing with the phone number example, the subattributes are only meaningful when held together as a collection. When posted as a Nested attribute, the entire collection represents a single instance, or value, of the nested attribute. Posts of additional collections are also valid and serve to accumulate additional nested attributes within the entity, relationship, or interaction data type.

When should you use the Nested attribute type?

Use the nested attribute type when you want to improve the appearance and usability of your UI. The Nested attribute provides greater flexibility to your UI designers and improves the navigation experience for business users. Nested attribute types can help you:

Make an attribute more customized, by including a broader collection of subattributes. For example, adding a phone number subattribute to a user profile attribute.
Group a set of attributes together to gain from their combined effectiveness. E.g., a person's physical description is clearer with several attributes.
Display Nested subattributes in the UI. The expand-collapse capability of the nested attribute type lets you display subattributes of a nested attribute separately in the UI. For example, you can define a Simple attribute type to capture singular physical details, e.g., eye color, hair color, height, and weight. Together, these simple subattributes comprise a Nested attribute type named physical description, and you can display each one, in the UI, independently or together.

Reference attribute type

You can use the Reference attribute type to enable a single entity to reference and make use of the attributes of another entity. The referencing increases reuse of attributes and saves you time. The entity now functions as if the attributes of both were defined natively in each entity. The reference attribute type can help ease the defining of relationships between entity types in your data model.

When should you use the Reference attribute type?

To reuse attributes between entities: You don't always have to define the attributes of every entity; some can share the attributes by reference. You can make an entity use the attributes of another entity without natively defining the attributes of both. For example, the L1 layer in the Reltio Multidomain MDM information model defines a relationship that links an Organization and an Individual using the affiliatedwith relationship type. The affiliatedwith relationship type defines the Organization entity type to be a reference attribute of the Individual entity type.
To make navigation between entities easier: in the example we just covered, the entity types are related using the affiliatedwith relationship type. The relationship type, then specifies an attribute of previous employer for the Individual entity type. This reference makes previous employer display as a hyperlink on the Individual’s profile facet. From there, the user can navigate easily to the Individual's previous employer.
To streamline refined search: when attributes of a referenced entity and relationship type are available to be indexed as though they were native to the referencing entity, business users can more easily refine search queries. For example, in a search of a data set that contains e.g., a hundred John Smith records, entering John Smith in the search box returns a hundred John Smith records. AddingAcme to the search criteria returns only those records with John Smith that have a reference, and so have an attribute, that contains the word Acme.

What you need to know before using reference attribute types:

Define relationship types: You must establish a relationship type between two entity types before you can define a Reference attribute. After you’ve defined the relationship type, you can assign one entity type to be a reference of the other. To learn more about defining relationship types, see Entity Relationships.
Immutability: when you have several entities that must reference the same attribute of another entity, you can mark all subattributes of that reference attribute as immutable for some sources. To learn more about avoiding the generation of multiple events, see Immutable Reference Attributes.
Operational Values (OV) and non-OV values. The Reference attribute type can contain both OV and non-OV values. To learn more about OV values, see Understanding the Reltio Entity Type.

Analytic attribute type

You can use the Analytic attribute type to receive and hold values delivered by an analytics solution, such as Reltio Insights. Use the Analytic attribute type when you want to make a value from your analytics solution available to a business user or to other applications using the Reltio Rest API.

What you need to know before using analytic attribute types:

Merges are managed differently. For example, during merge operations, the attribute is managed differently from other attribute types when records come together.
Data delivery to your analytics solution. For example, maybe your analytics implementation calculates a customer's lifetime value and you want that value to be available to users while they’re looking at the customer's profile. Define an analytic attribute to hold this value and to use for storing DVF notifications. To learn more about merging in Reltio, see Merging in the Reltio Platform.

The Generic Attribute Type

The Generic attribute types in Reltio allow you to define attribute configuration and behavior options and then streamline them.

Generic attribute types enable you to define attribute configuration and behavior options that can be applied to groups of specified entity attributes. Attribute types can define comparator and match token classes.

Use generic attribute types to streamline the configuration by reducing and centrally managing shared attribute configuration definitions.

Without generic attribute types With generic attribute types

Without generic attribute types	With generic attribute types
"entityTypes": [ { "URI": "configuration/entityTypes/Organization", "attributes": [ { "URI": "configuration/entityTypes/Organization/attributes/Name", "type": "String" }, { "URI": "configuration/entityTypes/Organization/AddressLine", "type": "String" } ], "matchGroups": [ { "URI": "configuration/entityTypes/Organization/matchGroups/MatchByName", "type": "suspect", "rule": { "fuzzy": [ "configuration/entityTypes/Organization/attributes/Name" ], "matchTokenClasses": { "mapping": [ { "attribute": "configuration/entityTypes/Organization/attributes/Name", "class": "com.reltio.match.token.ComplexOrganizationNameMatchToken" } ] }, "comparatorClasses": { "mapping": [ { "attribute": "configuration/entityTypes/Organization/attributes/Name", "class": "com.reltio.match.comparator.OrganizationNamesComparator" } ] } } }, { "URI": "configuration/entityTypes/Organization/matchGroups/MatchByNameAndAddress", "type": "automatic", "rule": { "fuzzy": [ "configuration/entityTypes/Organization/attributes/Name", "configuration/entityTypes/Organization/attributes/Address" ], "matchTokenClasses": { "mapping": [ { "attribute": "configuration/entityTypes/Organization/attributes/Name", "class": "com.reltio.match.token.ComplexOrganizationNameMatchToken" }, { "attribute": "configuration/entityTypes/Organization/attributes/Address", "class": "com.reltio.match.token.AddressLineMatchToken" } ] }, "comparatorClasses": { "mapping": [ { "attribute": "configuration/entityTypes/Organization/attributes/Name", "class": "com.reltio.match.comparator.OrganizationNamesComparator" }, { "attribute": "configuration/entityTypes/Organization/attributes/Address", "class": "com.reltio.match.comparator.DynamicDamerauLevenshteinDistance" } ] } } } ] } ]	{ "attributeTypes": [ { "URI": "configuration/attributeTypes/OrganizationName", "valueType": "String", "matchTokenClass": "com.reltio.match.token.ComplexOrganizationNameMatchToken", "comparatorClass": "com.reltio.match.comparator.OrganizationNamesComparator" }, { "URI": "configuration/attributeTypes/AddressLine", "valueType": "String", "matchTokenClass": "com.reltio.match.token.AddressLineMatchToken", "comparatorClass": "com.reltio.match.comparator.DynamicDamerauLevenshteinDistance" } ], "entityTypes": [ { "URI": "configuration/entityTypes/Organization", "attributes": [ { "URI": "configuration/entityTypes/Organization/attributes/Name", "type": "OrganizationName" }, { "URI": "configuration/entityTypes/Organization/AddressLine", "type": "AddressLine" } ], "matchGroups": [ { "URI": "configuration/entityTypes/Organization/matchGroups/MatchByName", "type": "suspect", "rule": { "fuzzy": [ "configuration/entityTypes/Organization/attributes/Name" ] } }, { "URI": "configuration/entityTypes/Organization/matchGroups/MatchByNameAndAddress", "type": "automatic", "rule": { "fuzzy": [ "configuration/entityTypes/Organization/attributes/Name", "configuration/entityTypes/Organization/attributes/AddressLine" ] } } ] } ] }

"entityTypes": [
    {
      "URI": "configuration/entityTypes/Organization",
      "attributes": [
        {
          "URI": "configuration/entityTypes/Organization/attributes/Name",
          "type": "String"
        },
        {
          "URI": "configuration/entityTypes/Organization/AddressLine",
          "type": "String"
        }
      ],
      "matchGroups": [
        {
          "URI": "configuration/entityTypes/Organization/matchGroups/MatchByName",
          "type": "suspect",
          "rule": {
            "fuzzy": [
              "configuration/entityTypes/Organization/attributes/Name"
            ],
            "matchTokenClasses": {
              "mapping": [
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Name",
                  "class": "com.reltio.match.token.ComplexOrganizationNameMatchToken"
                }
              ]
            },
            "comparatorClasses": {
              "mapping": [
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Name",
                  "class": "com.reltio.match.comparator.OrganizationNamesComparator"
                }
              ]
            }
          }
        },
        {
          "URI": "configuration/entityTypes/Organization/matchGroups/MatchByNameAndAddress",
          "type": "automatic",
          "rule": {
            "fuzzy": [
              "configuration/entityTypes/Organization/attributes/Name",
              "configuration/entityTypes/Organization/attributes/Address"
            ],
            "matchTokenClasses": {
              "mapping": [
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Name",
                  "class": "com.reltio.match.token.ComplexOrganizationNameMatchToken"
                },
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Address",
                  "class": "com.reltio.match.token.AddressLineMatchToken"
                }
              ]
            },
            "comparatorClasses": {
              "mapping": [
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Name",
                  "class": "com.reltio.match.comparator.OrganizationNamesComparator"
                },
                {
                  "attribute": "configuration/entityTypes/Organization/attributes/Address",
                  "class": "com.reltio.match.comparator.DynamicDamerauLevenshteinDistance"
                }
              ]
            }
          }
        }
      ]
    }
  ]

{
  "attributeTypes": [
    {
      "URI": "configuration/attributeTypes/OrganizationName",
      "valueType": "String",
      "matchTokenClass": "com.reltio.match.token.ComplexOrganizationNameMatchToken",
      "comparatorClass": "com.reltio.match.comparator.OrganizationNamesComparator"
    },
    {
      "URI": "configuration/attributeTypes/AddressLine",
      "valueType": "String",
      "matchTokenClass": "com.reltio.match.token.AddressLineMatchToken",
      "comparatorClass": "com.reltio.match.comparator.DynamicDamerauLevenshteinDistance"
    }
  ],
  "entityTypes": [
    {
      "URI": "configuration/entityTypes/Organization",
      "attributes": [
        {
          "URI": "configuration/entityTypes/Organization/attributes/Name",
          "type": "OrganizationName"
        },
        {
          "URI": "configuration/entityTypes/Organization/AddressLine",
          "type": "AddressLine"
        }
      ],
      "matchGroups": [
        {
          "URI": "configuration/entityTypes/Organization/matchGroups/MatchByName",
          "type": "suspect",
          "rule": {
            "fuzzy": [
              "configuration/entityTypes/Organization/attributes/Name"
            ]
          }
        },
        {
          "URI": "configuration/entityTypes/Organization/matchGroups/MatchByNameAndAddress",
          "type": "automatic",
          "rule": {
            "fuzzy": [
              "configuration/entityTypes/Organization/attributes/Name",
              "configuration/entityTypes/Organization/attributes/AddressLine"
            ]
          }
        }
      ]
    }
  ]
}

Simplify configuration of search options

You can provide search options for each attribute type:

"searchOptions" : [
			"tokenize : false,
			"caseSensitive" : true
			]

Attribute Types Configuration

Attribute types are configured as section "attributeTypes" of the Configuration API and used in configuration to define attribute value types of entities, relationships, and so on. Any attribute type can extend one of existing attribute types. Relto platform includes a base set of attribute types. Vertical specific attribute types can be implemented at the vertical layer. Layers can use already defined attribute types or declare new ones.

The following generic attribute types are defined in the Core Layer.

Table 1. Core Generic Attribute Types
Attribute Type	Value Type	Match Token Class	Comparator Class	Description
`OrganizationName`	String	`OrganizationNameMatchToken`	`EqfOrganizationNameComparator`	Recommended to use for organization name in case of worldwide companies. Uses extended noise words dictionary (including international garbage words) with stemming. Uses advanced set of delimiters to split value to words and stem them. Calculates distance between words using Hungarian algorithm and weights based on words frequency dictionary.
`AddressLine`	String	`AddressLineMatchToken`	`AddressLineComparator`	Recommended to use for address line.
`SimpleName`	String	`ComplexPhoneticNameToken`	`DynamicDamerauLevenshteinDistance`	Recommended to use for first/last name of person by default. Build phonetic token using dictionary for all characters.
`Email`	String	`TextMatchToken`	<Default Comparator Class>	Recommended to use for email. Use digits and a-z chars from values.
`PhoneNumber`	String	`PhoneNumberMatchToken`	`PhoneNumberComparator`	Recommended to use for phone numbers. Use digits from values.
`WebsiteURL`	URL	<Default token class>	`StringComparatorIgnoringNulls`	Recommended to use for URL.

The default match token/comparator class for an attribute depends upon in which rule this attribute is used. The defaults are:

Table 2. Attribute Rules
	Exact Rule	Fuzzy Rule
Default Comparator Class	`ExactMatchToken`	`FuzzyTextAndNumberMatchToken`
Default comparator class	`BasicStringComparator`	`DamerauLevenshteinDistance`

Generic Attribute Type Structure

A collection of Entity Types is defined for a configuration. Each entity type has the following properties:

Table 3. Entity Type Properties
Property Name	Required	Description	Type	Example
`URI`	Yes	Path that is used to reach the generic attribute type. It has format:`configuration/attributeTypes/{AttributeTypeName}`	String, URI	`configuration/attributeTypes/OrganizationName`
`extendsTypeURI`	No	URI of generic attribute type that is extended by this attribute type Note: You must provide either extends,`TypeURI` or `valueType` attributes	String, URI	`configuration/attributeTypes/OrganizationName`
`valueType`	No	Data type of attribute Note: You must provide either extends `TypeURI` or `valueType` attributes	String	String
`matchTokenClass`	No	Match token class which generates tokens for the field value	JSON Object	`{ "class": "com.reltio.match.token.RangeNumericMatchToken", "parameters": [{ "parameter": "<param_name>", "value": "<param_value>" }] }`
`comparatorClass`	No	Comparator class to use for comparing the attribute values of this type	JSON Object	`{ "class": "com.reltio.match.comparator.RangeNumericComparator", "parameters": [{ "parameter": "threshold", "value": "30" }] }`

Generic Attribute Type Example: Defining an attribute type for pharmacy organization name.

"attributeTypes": [{
	"URI": "configuration/attributeTypes/PharmacyOrganizationName",
	"valueType": "String",
	"matchTokenClass": {
		"class": "com.reltio.match.token.PharmacyOrganizationNameMatchToken"
	},
	"comparatorClass": {
		"class": "com.reltio.match.comparator.PharmacyOrganizationNameComparator"
	}
}]

Using Generic Attribute Types

Generic Attribute Type usage example:

"attributeTypes": [{
		"URI": "configuration/attributeTypes/ComplexName",
		"valueType": "String",
		"matchTokenClass": {
			"class": "com.reltio.match.token.ComplexPhoneticNameToken"
		},
		"comparatorClass": {
			"class": "com.reltio.match.comparator.DynamicDamerauLevenshteinDistance"
		}
	},
	{
		"URI": "configuration/attributeTypes/PhoneNumber",
		"valueType": "String",
		"matchTokenClass": {
			"class": "com.reltio.match.token.PhoneNumberMatchToken"
		},
		"comparatorClass": {
			"class": "com.reltio.match.comparator.PhoneNumberComparator"
		}
	}
],
"entityTypes": [{
	"URI": "configuration/entityTypes/ExampleType",
	"attributes": [{
			"URI": "configuration/entityTypes/ExampleType/attributes/Name",
			"type": "configuration/attributeTypes/ComplexName"
		},
		{
			"URI": "configuration/entityTypes/ExampleType/attributes/Phone",
			"type": "configuration/attributeTypes/PhoneNumber"
		}
	],
	"matchGroups": [{
		"URI": "configuration/entityTypes/ExampleType/matchGroups/FuzzyMatchByNameAndPhone",
		"label": "FuzzyMatchByNameAndPhone",
		"type": "suspect",
		"rule": {
			"and": {
				"fuzzy": [
					"configuration/entityTypes/ExampleType/attributes/Name",
					"configuration/entityTypes/ExampleType/attributes/Phone"
				]
			}
		},
		"matchServiceClass": "com.reltio.businesslogic.match.providers.internal.InternalMatchService"
	}]
}]

In this example, generic attribute types configuration/attributeTypes/ComplexName and configuration/attributeTypes/PhoneNumber are used for attributes Name and Phone of the entity type ExampleType respectively. One suspect match group is declared as fuzzy match entities using these attributes. Since there is no match token mapping nor comparator mapping in the rule, the match token classes and comparators from the corresponding generic attribute types are used for matching.

Note: match token class and comparator class defined in generic attribute type will be used only for attribute defined as fuzzy in match rule.

Supported Operations

Get Attribute Types Collection

This operation returns an array of Attribute Types defined in the configuration, for a tenant.

Request

GET {TenantURL}/configuration/attributeTypes

Parameters: No

Response

If there is a configuration defined for a tenant specified in Header of a request a JSON Array of generic attribute types is returned. If there is no such configuration - Error.

Errors:

309: Tenant '{0}' not defined in a system
310: Failed to process Reltio Business Model JSON loaded from Reltio data storage.

Request:

GET {TenantURL}/configuration/attributeTypes
Headers: Tenant: Test

Response:

GET {
	TenantURL
}
/configuration/attributeTypes
Headers: Tenant: Test Body: [{
		"URI": "configuration/attributeTypes/OrganizationName",
		...
	},
	{
		"URI": "configuration/attributeTypes/AddressLine",
		...
	},
	{
		"URI": "configuration/attributeTypes/PhoneNumber",
		...
	}
	...
]

Immutable reference attributes

Learn about immutable reference attributes and when they come in to play.

Immutable vs. mutable – Let’s be clear

In object-oriented and functional programming, you need to keep in mind that an object is only changeable under certain conditions.

Immutable -- In object-oriented and functional programming, an immutable object is unchangeable; it’s an object whose state can’t be modified after it’s created
Mutable -- In contrast to a immutable object, a mutable object is changeable and can be modified after it’s created.

Why does immutability matter?

You’ll want to enable the immutability of reference attributes in certain cases to avoid a change in the referenced entities and avoid generating multiple events due to non-significant differences in the source data.

Consider this example...

The reference attribute of an entity, say entity A, is a link to a part of the attributes of the referenced entity, entity B, and the relationship that connects these entities. If the values of these linked attributes in the entity B or the relation changes, then the entity A with the reference attribute also changes. Often, several entities are linked with the same referenced entity via the referenced attribute.

To take that further, there’s an entity of the type Individual with an Address reference attribute and with Location type for the referenced entity. It is possible for multiple Individual entities, such as A1, A2, A3, and A4, to have the same address. This means that their Address reference attribute points to the same Location entity. If the Location entity has changed, then all reference attributes of the entities A1, A2, A3, and A4 change too. So the Reltio Platform generates an ENTITY_CHANGED event for all these entities to propagate the changes to the search system, history, and matching system. If the same address is used for four entities: A1, A2, A3, and A4, these get defined in the source system with some non-significant differences:

A1: New York, Main Avenue 123
A2: New York, Main Ave. 123
A3: New York, NY, Main Avenue, 123
A4: New York, Main Avenue 123

Logically, since all the addresses are the same, they match the same Location entity after cleansing and matching. So when the Reltio software loads the entities into the platform, this happens:

Entity A1 loads, the software creates a Location entity B with the address New York, Main Avenue 123, and then generates an ENTITY_CREATED event for entity A1 and entity B.
Entity A2 loads, and since the address is the same, the software uses Location entity B as the referenced entity in the Address reference attribute, but the attributes of the Location entity change to New York, Main Ave. 123. As a result, the software generates an ENTITY_CREATED event for entity A2, and then generates an ENTITY_CHANGED event for entity A1 (because the reference attribute has changed) and for entity B.
Entity A3 loads, and since the address is the same, the software uses the Location entity B as the referenced entity in the Address reference attribute, but the attributes of the Location entity change to New York, NY, Main Avenue, 123. As a result, the software generates an ENTITY_CREATED event for entity A3, and then generates an ENTITY_CHANGED event for entities A1 and A2 (because the reference attribute has changed) and for entity B.
Entity A4 loads and the software uses the Location entity B as the referenced entity in the Address reference attribute. The final attribute values of the Location entity depend on the order in which the entities are loaded. In this example, the software loaded entity A4 last, so the location is the same as for entity A1.

How can I control the situation?

The above example demonstrates how minor, non-significant differences in the source data produces multiple unnecessary events. The results still display as if the Location entity were not changed at all. Using the immutable reference attributes feature enables you to ignore such differences and not generate unnecessary events, which improves the performance and stability. The order of loading entities, which is random, determines the result.

If you enable the feature and then load the data, as described in the example, the software only generates one event, ENTITY_CREATED for each entity.
If you don’t enable the feature, you always have values for the Location entity, which was loaded first, as opposed to values for the Location entity, which was loaded last.

Important facts about using immutable reference attributes!

Consider these facts:

Reltio recommends that you always enable the immutability of reference attributes when you use Location as the reference attribute.
The immutability of reference attributes only affects changes done through the reference attributes. If you update the referenced entity directly; that is, not as a part of the reference attribute of another entity, then the software always applies the changes, and all events are generated.
Changes are ignored only for attributes of the referenced entity, not for attributes of the relation. They update as expected.
If a new source data; that is, another crosswalk type or value, which does not exist in the referenced entity loads, then it’s added and the referenced entity updates as expected (with disabled immutable reference attributes).
If the entity with the reference attribute is updated, and the referenced entity in the new reference attribute does not match the current referenced entity, then two things can happen:
- A new referenced entity is created.
- The referenced attribute points to the existing entity, which matches the incoming data; that is, the reference attribute changes.

To learn which reference attribute properties you can use, see Metadata reference attribute properties.

Metadata reference attribute properties

Learn about the reference attribute properties available for your use.

Metadata reference attribute properties

When you customize the immutability of the reference attributes, you can use the reference attribute properties in the metadata configuration. Check out the following table:

Table 4. Available refrence attribute properties
Property	Type	Description	Default value
`immutable`	Boolean	Defines the immutability of the reference attribute.	The default value is set to `true` for all tenants created after `09/22/2021` and `false` for all other tenants.Note: To change the default value for your tenant, contact Reltio Support Portal.
`immutableForSources`	Array of URIs for sources (String)	Defines the immutability of the selected sources. If the `immutable` property is set to `false`, then the `immutableForSources` property enables the immutability for the selected sources, so that changes are always ignored.	The default value is an empty array.
`immutableExceptForSources`	Array of URIs for sources (String)	Defines the immutability of the selected sources. If the `immutable` property is set to `true`, then the `immutableExceptForSources` property disables the immutability for the selected sources, so that changes are always applied.	The default value is an empty array.

Examples of immutable reference use

The immutable property defines the immutability of the reference attributes. When this property is enabled, it is not possible to change the value of the sub-attributes that came from the referenced entity, although you still can change the values from the relation.

Using the immutableForSources property, it is possible to define an array of source systems (with URIs and IDs) for which the sub-attributes become immutable. This can be done inside the business configuration as shown in the example:

{
          "uri": "configuration/entityTypes/HCP/attributes/Address",
          "relationshipLabelPattern": "rank - {AddressRank}",
          "referencedAttributeURIs": [
            "configuration/relationTypes/HasAddress/attributes/AddressType",
	    ...
            "configuration/entityTypes/Location/attributes/AddressLine1",
            "configuration/entityTypes/Location/attributes/AddressLine2",
            "configuration/entityTypes/Location/attributes/City",
            "configuration/entityTypes/Location/attributes/Zip",
	    ...
          ],
          "immutableForSources": [
            "SOURCE_SYS_001", "SOURCE_SYS_002"
          ]
        }

In this example, it is not possible for the HCP to change the address attributes loaded from the SOURCE_SYS_001 and SOURCE_SYS_002 source systems. For example, some HCPs may reference the same Location entity, and the Location entity has a crosswalk X, which is from the SOURCE_SYS_001source. Now, if a request is sent to add or modify any HCP with the same Location entity, that is, with the same crosswalk, then this change is ignored and the Location entity remains unchanged.

When you set the immutable property to true, you can specify which entity attributes to consider as immutable when uploading similar entities. For example, even if a Location entity is marked as immutable but changes are made, then you must send a request to modify the Location entity.

The immutableExceptForSources property is the opposite of the immutableForSources property. You can use it with the immutable property when you must have a white list of sources. The attribute values that come from provided sources will change the address attributes.

Example 1: Updating an Existing Crosswalk

In this scenario, the sub-attributes of the HCP are not changed.

Step 1: Post an L3.

"immutableForSources":[
            "HMS", "configuration/sources/NPI"
          ]

Step 2: Post the HCP code.

[
  {
    "type": "configuration/entityTypes/HCP",
    "attributes": {
      "FirstName": [{"value": "FirstName01"}],
      "LastName": [{"value": "LastName01"}],
      "Address": [
        {
          "value": {
            "AddressLine1": [{"value": "AddressLine 1"}],
            "Country": [{"value": "Country 1"}],
            "City": [{"value": "City 1"}],
            "StateProvince": [{"value": "State 1"}]
          },
          "refEntity": {
            "crosswalks": [
              {
                "type": "configuration/sources/NPI",
                "value": "locXwalk"
              }
            ]
          }
        }
      ]
    },
    "crosswalks": [
      {
        "type": "configuration/sources/NPI",
        "value": "hcpXwalk01"
      }
    ]
  }
]

Step 3: Post the HCP attributes such as a new HCP name, reference attributes with the Location entity and with the same existing crosswalk, but with another value for the AddressLine1 attribute.

[
  {
    "type": "configuration/entityTypes/HCP",
    "attributes": {
      "FirstName": [{"value": "FirstName02"}],
      "LastName": [{"value": "LastName02"}],
      "Address": [
        {
          "value": {
            "AddressLine1": [{"value": "AddressLine 2"}],
            "Country": [{"value": "Country 1"}],
            "City": [{"value": "City 1"}],
            "StateProvince": [{"value": "State 1"}]
          },
          "refEntity": {
            "crosswalks": [
              {
                "type": "configuration/sources/NPI",
                "value": "locXwalk"
              }
            ]
          }
        }
      ]
    },
    "crosswalks": [
      {
        "type": "configuration/sources/NPI",

        "value": "hcpXwalk02"
      }
    ]
  }
]

Result: The system creates a new HCP and uses the existing Location entity, because it will be merged with the crosswalk. However, the system doesn't change the value of the AddressLine1 attribute because NPI is marked as immutable. Also, a crosswalk of this type already exists with the locXwalk value for the Location entity.

Example 2: Updating the Existing Surrogate Crosswalk

In this scenario, the sub-attributes of the HCP are changed.

Step 1: Post an L3.

"immutableForSources":[
            "HMS", "configuration/sources/NPI"
          ]

Introduce a surrogate crosswalk for the Location entity:

"surrogateCrosswalks":[
   {
      "source":"configuration/sources/HMS",
      "enforce":true,
      "attributes":[
         "configuration/entityTypes/Location/attributes/AddressLine1",
         "configuration/entityTypes/Location/attributes/City",
         "configuration/entityTypes/Location/attributes/StateProvince",
         "configuration/entityTypes/Location/attributes/Zip/attributes/Zip5",
         "configuration/entityTypes/Location/attributes/Country"
      ]
   }
]

Step 2: Post the HCP attributes.

[
  {
    "type": "configuration/entityTypes/HCP",
    "attributes": {
      "FirstName": [{"value": "FirstName01"}],
      "LastName": [{"value": "LastName01"}],
      "Address": [
        {
          "value": {
            "AddressLine1": [{"value": "AddressLine 1"}],
            "Country": [{"value": "Country 1"}],
            "City": [{"value": "City 1"}],
            "StateProvince": [{"value": "State 1"}]
          },
          "refEntity": {
            "crosswalks": [
              {
                "type": "configuration/sources/HMS",
                "value": "Surrogate"
              }
            ]
          }
        }
      ]
    },
    "crosswalks": [
      {
        "type": "configuration/sources/HMS",
        "value": "hcpXwalk01"
      }
    ]
  }
]

Step 3: Post the HCP attributes such as a new HCP name, reference attributes with the Location entity and with the same existing crosswalk, but with another value for the AddressLine1 attribute.

[
  {
    "type": "configuration/entityTypes/HCP",
    "attributes": {
      "FirstName": [{"value": "FirstName02"}],
      "LastName": [{"value": "LastName02"}],
      "Address": [
        {
          "value": {
            "AddressLine1": [{"value": "AddressLine 1"}],
            "AddressLine2": [{"value": "AddressLine 2"}],
            "Country": [{"value": "Country 1"}],
            "City": [{"value": "City 1"}],
            "StateProvince": [{"value": "State 1"}]
          },
          "refEntity": {
            "crosswalks": [
              {
                "type": "configuration/sources/HMS",
                "value": "Surrogate"
              }
            ]
          }
        }
      ]
    },
    "crosswalks": [
      {
        "type": "configuration/sources/HMS",

        "value": "hcpXwalk02"
      }
    ]
  }
]

Result: The system creates a new HCP and uses the existing Location entity, because it will be merged with the crosswalk as the posted Location entity will have the same crosswalk value as the existing Location entity. However, the system doesn't add the value of the AddressLine2 attribute because HMS is marked as immutable. Also, a crosswalk of this type already exists with the same value for the Location entity.

Configuring Attributes

Attributes are defined as a collection in the entityTypes section of the configuration file.

Analytic attributes are special attributes that are used to store analytic results.

Configuring Simple Attributes

Simple attributes are defined by setting the type element.

Note: An attribute is understood to be a Reltio Simple attribute by setting its type to a data type such as string, int, and others. For Nested and Reference attributes, you must set the type to Nested or Reference.

Data is created using the POST method to send a JSON formatted file to the data API:

Submit to:

POST {TenantURL}/entities

Configuring Nested Attributes

Nested attributes are defined by setting the type element to nested.

Data is shown in the following figure.

Submit to:

POST {TenantURL}/entities

Configuring Reference Attributes

Reference attributes are defined by setting the type element to reference.

A Reference attribute can be displayed in two different ways in UI:

An Entity can have multiple references to another entity, with different relation types.
"Relationship Facets" display data for related entities (select the hyperlink to see the profile view of the related entity).

Note: See the Relationships in the related links for details about how to create data for a reference attribute.

Configuring Analytic Attributes

Analytic attributes are special attributes that are used to store analytic results.

Analytic attributes are populated by Reltio Data Science. The Analytic API includes them into returned entities and supports searching by analytic attributes values.

Analytic attributes are the properties of an entity. There are two types of analytic attributes: Simple and Nested. Nested attributes contain a set of analytic attributes. Analytic attributes can contain multiple values, maximum number of values is limited by the maxOccurs property.

Analytic Attributes are defined as a collection within the entityTypes section of the configuration file:

"entityTypes": [{
 "URI": "configuration/entityTypes/Party",
 "label": "Party",
 "description": "Organization entity type details",
 "abstract": true,
 "attributes": [...],
 "analyticsAttributes": [{
 "URI": "configuration/entityTypes/Party/analyticsAttributes/Name",
 "name": "Name",
 "label": "Name",
 "type": "String",
 "description": "Name"
 }]
}]

Accelerate the Value of Data

Reltio attribute types

Simple attribute type

Nested attribute type

Reference attribute type

Analytic attribute type

The Generic Attribute Type

Simplify configuration of search options

Attribute Types Configuration

Generic Attribute Type Structure

Using Generic Attribute Types

Supported Operations

Immutable reference attributes

Why does immutability matter?

Important facts about using immutable reference attributes!

Metadata reference attribute properties

Metadata reference attribute properties

Examples of immutable reference use

Configuring Attributes

Configuring Simple Attributes

Configuring Nested Attributes

Configuring Reference Attributes

Configuring Analytic Attributes

Footer