Taxonomies and option lists
Navigating taxonomies and options lists is a key aspect of effective schema management. This article explains how to choose between taxonomies and option lists, helping you make an informed choice based on your needs. It also provides best practices for naming these structures, ensuring clarity and consistency.
Choosing between taxonomies and option lists
Setting up your data model comes with a recurring question: do I use an option list or a taxonomy? It is crucial to choose the proper data format to have a high-performing application with the required features.
This section contains recommendations and guidance to help you decide when to use taxonomies in your data model, and when to use option lists.
Use the following table to choose between taxonomies and option lists:
|
Precondition |
Taxonomies |
Option lists |
|---|---|---|
|
You have a long list of values |
Used when you have an extensive list of 50 or more values. Avoid using more than 300 values, as this is likely to cause performance issues. |
Used when you have a controlled vocabulary list with fewer than 50 values. |
|
You need to set security rules based on values |
Used to apply security model rules based on taxonomy values. For example, Fruitful brand approvers can only approve assets from the Fruitful brand, not others. |
Can't contain security properties. Used when security rules aren't needed based on values. |
|
You need to inherit your values |
Used to create facets in search pages. |
Can't inherit from your data model family tree. For example, if you have an option list in the M.ProductFamily definition, you cannot show it as a facet filter on the Products search page. |
|
You need to include more information than just the primary values alone |
Can hold additional properties, for example descriptions, as schema definitions. |
Can't hold more than the value of the controlled vocabulary, because option lists are simple data sources. |
|
You need a hierarchy with more than five levels |
Have no limits in the number of hierarchy levels they can carry. |
Limited to a simple five-level hierarchy. |
|
You need to display data on the entity details page and Search component |
Used for data displayed on the entity details page and Search component. |
Used for data displayed only on the entity itself. |
Naming conventions
Naming schemas and taxonomies consistently, logically, and predictably lets you distinguish more easily between similar schemas and taxonomies. Content Hub has a prebuilt data model that includes taxonomies with names that are prefixed with M (for example, M.entityDefinitionName or M.TaxonomyName).
When you define your data model, we recommend that you do the following:
-
Define and apply your personalized naming convention to your schema and taxonomies, similar to the Content Hub prebuilt model. Start any new definition or taxonomy name with a consistent prefix. It is common practice to keep this related to the name of the application or the customer. For example, the company XYZ might name their new taxonomy XYZ.Taxonomy or XYZ.Definition.
-
Name your relations systematically. When you define a relation between two definitions, write the name of the parent entity definition first. For example, if you want to relate Brand and Asset definitions, name your relation BrandToAsset.
Taxonomy names can only contain letters, periods, and underscores.