Paths across entity definitions

Context

Path between entities is an important concept in Content Hub who allow to get additional information between entities in the same path. It is commonly misunderstood and demands a thorough and deliberate approach.

When an entity has many related paths, it requires loading a lot of entities, which might impact performance. Only configure Path Enabled Definition and Related Path when you have a real use case.

Execution

A path is a trail showing a hierarchical structure between entities. The path contains the name and the ID of the different entities linked together. Paths are used to visualise the hierarchy of entities linked and to show on entity details page information from parent entities included in the path.

Examples of paths include -

1. Asset Type: Taxonomies with different levels are shown on Asset details page.
2. Product path on Asset: The path includes Brand, Product Family and Product and is shown Assets Search page.

Path configuration in Content Hub can be configured by using the following options:

1. On the Entity definition

Path enable definition toggled on Indicates that entities of this definition can be part of entity paths. This option can be activate when you edit a definition.

2. On the Relation

• Path relation: Creates a related path on the child side of the relation. This allows for path expansion of hierarchical entities on a related entity.
• Is path hierarchy relation: Connects path-enabled definitions and hierarchical definitions, creating a path hierarchy. This is usually set on self-relations.
• Path hierarchy score: If an entity has multiple parent relations, the paths of that entity are sorted in ascending order according to this score. Unless marked otherwise, the first path is used as a sole entity path when only one is required.

Insights

hen an entity has many related paths, it requires loading a lot of entities, which might slightly impact performance. Related paths are computed on the fly, thus their impact on the storage is minimal. Paths however, are computed and stored in the main meta–data storage for all the path–enabled entities. The computation of the paths happens during the search indexing process of the entities.

Paths themselves have a non trivial, though small, memory footprint. This does not normally cause issues. However, paths (not related paths) should not be enabled and are not intended for entity definitions with significant amounts of entities (for example, M.Asset or M.File). You can consider the paths as a form of data classification which sorts large groups of data rather than classifying every single piece of data.

Computation of the paths for large pools of entities has an impact on system performance and uses a large portion of the main metadata storage.

Only configure Path Enabled Definition and Related Path when you have a real use case need. For example, by default when a taxonomy relation is created, Path relation is set to True and it is not always needed, in particular for taxonomy with only one level of data (non hierarchical taxonomy).

The Use Case Perspective

Let’s take this approach and apply it to real-life use cases to see it in action.

Multi-level taxonomy example Geography

This use case shows how to build a Path between the Geography hierarchy and assets. In our example, Geography hierarchy is a taxonomy with a self relation to link Geography to Geography.

The configuration on the schema should include -

• Geography has Path Enabled Definition equal to True to be part of the entity path.
• Relation Geography - Asset has Path relation equal to True as we want to create a related path on the child side of the relation and Is Path Hierarchy relation equal to False as there is no need to have Asset entities in the path.

By default,

• When a taxonomy is created Path enabled definition is set to True
• When a taxonomy relation is created Path relation is set to True and Path hierarchy is set to False

Show Path information in search component, entity details component.

Path Across multiple entity definition example Product Hierarchy

This use case shows how to build a Path between the product hierarchy and assets. In our example, product hierarchy is composed of Brand, Product Family and Product.

As shown in the following diagram, Brand is parent of Product Family, Product Family is parent of Product and Product is parent of Asset.

This objective is to be able to show this path on the asset level and to show information from Brand, Product Family and Product on the Asset Details page.

The configuration on the schema should include -

1. Brand, Product Family and Product have Path Enabled Definition equal to True to be part of the entity path.
2. Relations Brand - Product Family and Product Family - Product have Path relation equal to False as there is no need to create a related path on the child side of the relation and Is Path Hierarchy relation equal to True to connect Path enabled entity definition.
3. Relation Product - Asset has Path relation equal to True as we want to create a related path on the child side of the relation and Is Path Hierarchy relation equal to False as there is no need to have Asset entities in the path.

The following diagram shows the schema configuration required to have a Product Hierarchy path on the assets.

In the examples below, the Brand is “Fruitful”, Product Family is “Fruitful Lemonade” and Product is “Fruitful Lemonade - Lime”.

Path can be used for:

1. Show Path information in search component, entity details component.

   

2. Show detailed information from Parent entities (Brand, Product Family and Product) on Asset details page by using an entity details component. Images below show the result and the configuration to have Product Family information available on Asset Details page.

   

   

3. Use the Path in integration to retrieve in one call parents entities included in the path. Image below shows an example of API call on an Asset entity showing the path from Brand to Product linked to the Asset.

Related Documentation