Term sets often start out their lives with an isolated purpose but, before we know it, we have multiple areas of the organization depending on them. It is often only after they have taken on their enterprise role that the cracks in their design start to show. By that stage a lot of content is tied to them and that can complicate re-organization.
Having arrived at that point more often than I'd like, with term sets that re-use from other term sets, I've wondered whether we could get more scientific about term set design and see red flags earlier. This post proposes that analysing the cardinalities in the domain model can reveal at least one such red flag.
The outcome in a nutshell
- Implement a one-to-one relationship as a (reversible) third composite term set
- Implement a one-to-many relationship as a (non-reversible) third composite term set
- Generally, avoid implementing a many-to-many relationship as a third composite term set
The first two are trivial but lay a foundation for talking about the third, which highlights an anti-pattern.
It will be assumed that you’re already following a practice of establishing elementary base term sets and then reusing from those, uni-directionally, into composite term sets, as discussed in
Good Practice: Update Single Identity in Taxonomies.
The principle there is you don’t want terms with the same meaning being duplicated with different identities. Rather define them as simple, uncontroversial components in one place and then re-use those building blocks in other arrangements to address the various perspectives the organization needs.
Start with a domain model
Constructing a domain model is an important starting point. This is not a technical model but a conceptual model of the real world, covering those things that are relevant to the current scope. If term sets are to fit the world naturally, they must be based on a model that properly describes the real world.
Clear definitions are essential since they will help ensure that base term sets are constrained to single, unambiguous concepts. Unconscious mixing of concepts leads to downstream problems.
The following will serve as a sample domain model for this post.
In case you're unfamiliar with the crow’s foot notation here is how it should be read.
The examples have been chosen so as to cover the three main cardinality types.
A Geopolitical Location contains zero or more Sites
A Site is located in one and only one Geopolitical Location
A site has one and only one General Manager
A General Manager manages one and only one Site
A Site is operated by one or more Business Units
A Business Unit operates at one or more Sites
will differ across organizations. Perhaps in your business a Site is operated by one and only one Business Unit.
The data model will have a direct impact on how your term sets are structured, so it’s important to ensure that it depicts your domain accurately.
My argument is that the presence of any many-to-many relationship represents a red flag.
With a domain model defined, we'll now move on to the corresponding term set patterns.
Pattern A: Implement a one-to-one relationship as a (reversible) third composite term set
1:1 relationsips are straightforward to implement.
If there is a need to represent the combination of two entities then introduce a third term set which corresponds to the associative entity between the first two entities. Re-use terms from the two base term sets into the composite one.
One site (such as Calcutta Operations) has one and only one general manager (Sam Govender).
Since this relationship is symmetrical, the term set structure can be reversed. General Managers may be placed beneath Sites or Sites beneath General Managers - whatever suits the purpose.
Resist the urge to get away with only two term sets. Keeping the base term sets elementary is more scalable since they could be arranged into a variety of other combinations in other term sets.
This is pretty obvious. Let's move on to the next pattern.
Pattern B: Implement a one-to-many relationship as a (non-reversible) third composite term set
In this example, to be more realistic, we're using a base geopolitical locations term set that already has some hierachy of its own. Don't let that confuse you. Each term still corresponds to a single
entity in the real world such as India or United Kingdom.
In the case of one-to-many relationships, a third term set will also usually be introduced which corresponds to the associative entity. This starts out the same as for one-to-one relationships. In contrast, however, the top level terms here are always derived from the entity at the singular end and the bottom level terms from the multiple end of the relationship.
One geopolitical location (such as India ) has many sites (Calcutta Operations, Calcutta Sales Office).
Avoid implementing a many-to-many relationship as a composite term set
It is tempting to combine the elements of a many-to-many relationship into a composite term set, but doing so is usually a mistake.
The term set story for many-to-many relationships is not great. SharePoint term sets are simple hierarchies and each term set can consume a term only once. In the above, I was therefore forced to create the last term as a duplicate of
Global Sales Office and
thus begins the slippery slope of losing single identity. We'd now end up with Global Sales Office documents tagged with different IDs across the landscape and so lose our ability to reliably locate all documents that pertain to that office.
So what to do? In my opinion M:N should resolve to separate term sets and fields in most cases. Instead of trying to combine the
Business Units and
Sites term sets into one I would keep them apart and present them as separate fields.
Starting with a domain model helps to avoid pitfalls when designing data structures. This holds true for SharePoint term sets.
In particular, beware of many-to-many relationships. They do not translate well into combined term sets.