“I know not how it was–but, with the first glimpse of the building, a sense of insufferable gloom pervaded my spirit.” – Edgar Allen Poe, The Fall of the House of Usher

I consider well-constructed semantic models akin to constructing a foundationally sound, well-architected, and visually appealing building. Not to be hyperbolic and melodramatic, because [swoon] that just isn’t me, has any taxonomist looked upon the works of others and despaired? Upon casting eyes upon and getting the “first glimpse of the building” that is the organizational semantic structure, suddenly felt “a sense of insufferable gloom” pervading the spirit? Boy howdy, have I.

To be fair, there are a number of factors at work leading to semantic debt; compromises in semantic integrity violating best practices in taxonomy construction left for some future taxonomist to unwind. These can be strong organizational cultural pushback to accepting taxonomies in structure or content, internal politics, or designing so that consuming systems can ingest the data. In any case, violations in taxonomy best practices can compound over time, leaving the semantic models in the current state not particularly semantic at all.

While it is mission-critical to gather input from business stakeholders to build, implement, and maintain taxonomies, it is also critical to allow the respective subject matter experts in taxonomy and business to do their work according to the best practices of their domains. Like a building drafted by M.C. Escher and constructed by Edgar Allen Poe & Associates, taxonomies can become circuitous, recurring, and not very meaningful if straying too far from best practices.

Escherian Design

I have frequently been involved in taxonomy design projects in which the stakeholder input into the semantic structures follows a line of thinking mirroring the work the business users do. In fairness, taxonomies should support whatever use cases assist end users in performing their jobs. However, business stakeholders are not necessarily taxonomists and so their recommendations may not follow taxonomy design principles. Here are some taxonomy design suggestions I have seen.

Taxonomies as virtual end caps. In this scenario, product owners try to mirror their product placement in the physical world as taxonomy structures in the virtual world. So you may get suggestions to build taxonomies like this:

Lumber > Deck building materials > Nails

Roof building materials > Shingles > Nails > Roofing nails

In essence, the concept representing the objects in the physical world are placed in the same locations in taxonomies as they would be in the layout of the store. The terms become conceptual end caps, quick items to throw in your cart because they are related to the products you are purchasing. In this case, I need nails for specific reasons, like building a deck or putting on a roof. For convenience, I put an end cap display of nails in the lumber department or by the stacks of shingles so buyers don’t need to hit every department to complete a project.

Taxonomies as navigational structures. While taxonomies can absolutely be used as navigational structures on the front end, the proposal here is that taxonomies exist this way in the back end taxonomy management system. Taxonomies may then be built like this:

Apparel > Men’s > Basketball shoes

Apparel > Women’s > Basketball shoes

From an access perspective, these are easy to understand navigational pathways leading directly to a set of products I can then filter by size, color, or brand to see what’s available but also make it easy to make a purchase.

Taxonomies as processes, stages, or funnels. Building taxonomies following process steps, stages, or trying to capture marketing user journeys through the funnel so that structures can look like this:

Awareness > Consideration > Conversion > Loyalty

Planning > Design > Prototype > Design for manufacturing > Manufacturing > Post-manufacturing

In this case, the sequential steps or stages are nested as a hierarchy as if to illustrate the progression through the process as a ladder or directional move through the concepts.

These are just a few of the examples I’ve experienced when working with stakeholders in the taxonomy design process. What’s wrong with giving the end users what they want by designing enterprise taxonomies to adhere to some of these patterns?

Maurits “Context” Escher

“If everything means everything, then nothing means anything.” Like Rick from Rick and Morty, I’m trying to build a following around a catchphrase. I made this same point in my blog Polyhierarchy and the Dissolution of Meaning. Repeating the same concept in multiple locations, whether trying to mirror real-world endcaps or to capture new contextual meanings from hierarchical placement, is a big taxonomic no-no and for good reason. If concepts become contextually dependent, then the individual subjects and objects within a semantic model lose their crisp focus. The point of taxonomies is to disambiguate concepts and ensure that each item is clearly defined in meaning and scope. Of course there are concepts that really can exist in more than one location in a polyhierarchical structure, but these occurrences should be minimal and not be forcing different contextual meanings.

Using the above examples, “nails” violates the “is a…” principle in that they are not semantic children of their parents. They are necessary items to complete a deck or a roof, but they are not decks or roofs themselves. We can easily build separate, mutually-exclusive taxonomy schemes or branches and connect them with semantic relationships to include all of the items necessary to build a deck or put a roof in place. Nesting them in contextual proximity is not following taxonomy best practices and, ultimately, causes ingestion confusion when stripped from context. More practically, repeated concepts will likely break a consuming application when the system finds the same label (and, if built properly in a taxonomy management system, same URI) showing up in two different locations. These are often ignored on ingestion because the system can not resolve the entities.

Building Codes and Accessibility

If you’ve seen any architectural drawings by Escher, you probably know that not only would they be very difficult to build in the real world even by Edgar Allen Poe & Associates, they would never pass local and state building codes for accessibility. Look at all those stairs! Not a ramp or elevator in sight!

Providing accessibility to products (or content) using navigational taxonomies is an excellent way to assist users in getting to what they are looking for. While there are more searchers than navigators in the world, simple drilldowns to products or content in hierarchies in conjunction with filters is still useful as an additional means of locating products or information. Navigational taxonomies rely on their contextual construction to provide signposts for users to know exactly where they are in the product structure and in the potentially very large “store” they are trying to navigate. Pretty self-explanatory name for these types of taxonomies.

Navigational taxonomies can be built directly in front-end applications to serve retail and information finding use cases. If possible, the values can come from back end taxonomy management systems to ensure consistent concepts and messaging across the organization. In these cases, the front end system may consume values from across the taxonomy schemes and hierarchies and display them in a different contextual hierarchy or as filtered values in left-hand navigations. It may also be possible that the taxonomy management system allows for the construction of semantic master schemes which can be reassambled in the tool or through the API into navigational hierarchies. Using our example above, the taxonomies behind the scenes may look like this

Products > Apparel > Footwear > Basketball shoes

People > Demographics > Men’s

In this case, only the values needed to construct a navigational taxonomy are pulled from their respective schemes and reassembled. The advantage to this methodology is that one best, preferred concept label and its unique ID are used in all locations. Any tagging to product images, copy, web pages, or concepts used in navigational structures or filters can be used for a variety of analytics including clicks on navigational nodes or filters, clicks on product images, analysis of products added to carts, etcetera, without having to reconcile the same or similar values for analysis.

Temporal Ladders

Taxonomy structures typically follow a parent-child “is a” structure in which the children are instances of their parent concepts. It is also possible to construct whole-part relationships (called meronymy in linguistics) in which the children are a part of the parent concept.

While it is possible to model temporal or sequential events in taxonomies and ontologies, it typically requires advanced skills in ontology modeling, can be challenging to implement, and can be subject to change when trying to mirror processes. Processes are not only sequential, but can change frequently as well. Changing a foundational semantic structure to keep in pace with changes in marketing funnels or manufacturing processes may not be worth the effort if the steps can be created taxonomies independent from their hierarchical structure.

That all said, using relationships to define sequence rather than hierarchical structure can be one simple way to create a semantic sense of order. For example, using a relationship like has predecessor could link books, films, or process steps in order to model sequence.

It’s all a Question of Time

As context graphs are gaining momentum in at least understanding if not yet implementation, we will likely see more ways to bridge the taxonomy modeling-temporal process gap. In the meantime, adhering to foundational taxonomy best practices is a best bet to ensure that your semantic models are ready for the next evolution to capture temporal events to provide additional context to the graph.

In short, maintaining “is a” or whole-part taxonomy structures as base semantic models while developing more complex ontological designs and connected data as part of a context graph will potentially provide a good combination to avoid Escherian design practices and Gothic horror in your semantic structures.