Configuring Relationship Types

Configuring the Relationship type involves configuring all the concepts and properties the object can contain, which drive the behavior of the object.

In the Relationship type, the following concepts are available for configuration:

  • Attributes
  • Start Object (entity type)
  • End Object (entity type)

Examples of relation types are:

  • Parent
  • Sister
  • Subsidiary
  • Division
  • Affiliated
  • Contractor

A configuration might have a collection of relation types. Each relation type has the following properties:

Table 1. Relation Type Properties
Property Name Required Description Type
URI Yes Path that is used to reach this relationship type configuration. The format is:configuration/relationTypes/{TypeName} String, URI
id Yes, for response JSON Internal, system-generated id that is used internally to get the difference between two versions of configurations when the configuration is updated. String
label Yes Readable name of the relationship type. String
description Details, description for the relation type. String
extendsTypeURI URI of relation type is extended by this relation type. String, URI

Collection URI of the relation type that has the same semantics as this type. In all graphs the configuration of these relation types is used as synonyms; therefore, there is no need to list all possible types in the graph configuration.

Example: "attorney" and "lawyer" relation types.

(/*To be supported*/)

reverseOfTypeURIs   Collection of URIs that define the semantic reverse relation type as this type.

Example: "parent" relation type; reverse is "child" relation type.

(/*To be supported*/)

implicit If TRUE, the relationship is marked as an Implicit relationship.
  • Implicit Relationships that do not appear, for example, in a Network graph because they are deemed not to be of significant business value in a graphical display. Implicit relationships are used only in Business Objects for reference attributes such as Address, where, again, its not considered important to render that relationship.
  • Explicit Relationships such as this between an Individual and an Employer are displayed in a graph.

Default is false; that is, explicit.

direction   Identifies directional semantics of relationship object of the type. Supported directions:
  • directed: Used when the two nodes that the relationship connects have different business meaning relative to each other. Example: When the "parent" relationship type is used, it is understood that one node is a parent, and the other node is the child.
  • undirected: Used when connecting node A to node B, and there is no reverse relationship implied. Example: "professional" might be used to connect a cardiologist to a neurosurgeon. A reverse relationship is neither required nor implied.
  • bidirectional: Both objects in the relationship are equal and active in a system. Start and end entity types must play the same role. Example: "friendship" relationship in FB (when both sides confirmed that they are friends).

Default is directed.

Enum:directed, undirected, bidirectional
entityEndDateStrategy   Defines how to handle the relation when the start/end entity is end dated.
  • END_DATE_RELATION: End date the whole relation and related crosswalks
  • END_DATE_RELATION_CROSSWALKS: End date related relation crosswalks. Defaults to END_DATE_RELATION_CROSSWALKS
typeColor Color that is used to visualize this relationship objects of that type (for example, in graph view-color of lines between nodes). String, hex color

Pattern that is used to build entity object tooltip. Can include static text as well as patterns - attributes in brackets.

Note: If the pattern is not specified, then the type's label is used.

Attributes that are defined as standard for this entity type. Attributes for relationships can be of simple, atomic type (refer to Attributes Configurationfor more details).

Note: Not every relation object will have all attributes defined in its relation type. Also, the relation object can have some attributes that are not defined in configuration-custom attributes.

(/*to be implemented*/)

JSON object of Attributes Configuration
startObject Yes, when inheritance is applied Defines properties of start object like its type (directional context).
endObject Yes, when inheritance is applied Defines properties of end object like its type( directional context).
	"URI": "configuration/relationTypes/Parent",
	"label": "Parent",
	"name": "Parent",
	"description": "Types of relationships between Individual and Individual-representing Parent-child relationship type",
	"extendsTypeURI": "configuration/relationTypes/Family",
	"reverceOfTypeURIs": ["configuration/relationTypes/Child"],
	"implicit": false,
	"direction": "directed",
	"typeColor": "#AA3A44",
	"startObject": {
		"objectTypeURI": "configuration/entityTypes/Individual",
		"directionalContext": [{
				"rule": [{
					"attribute": "configuration/entityTypes/Individual/attributes/Gender",
					"type": "condition",
					"condition": "=",
					"value": "Female"
				"labelPattern": "mother"
				"rule": [{
					"attribute": "configuration/entityTypes/Individual/attributes/Gender",
					"type": "condition",
					"condition": "=",
					"value": "Male"
				"labelPattern": "father"
				"labelPattern": "parent"
	"endObject": {
		"objectTypeURI": "configuration/entityTypes/Individual",
		"directionalContext": [{
			"labelPattern": "child"
Note: Currently, "id" parameters are not supported.