“Do what they say / Say what they mean / One thing leads to another.” – One Thing Leads to Another, The Fixx

Are your consumers overwhelmed by a barrage of terms and phrases coming at them from your taxonomy? Are they at a loss when faced by seemingly endless and contextless values presented in a taxonomy-fed typeahead field? How can you ask your taxonomy to manner up and find its filter? 

Taxonomists love their taxonomies. They don’t want to see the progeny they’ve so lovingly curated act inappropriately, particularly when it comes to throwing out values which don’t have context or are incorrect for the tasks they are intended to support. As taxonomies mature, they grow both in depth and breadth, becoming more refined and nuanced while also covering more topics and use cases. Building meaningful taxonomies with clear semantic hierarchies is the desired goal when developing enterprise knowledge models for delivery to consuming systems. As an organization’s use cases grow more numerous, however, the complexity involved in delivery can often roll back into taxonomies, forcing compromises and workarounds which further complicate future scalability and context.

I touched on this conundrum briefly in my January blog, “Polyhierarchy and the Dissolution of Meaning” in which I discuss separating semantic taxonomies from navigational and information access taxonomies consumed by downstream systems. It’s rare that consumers want every value from every taxonomy built as part of an overall enterprise ontology. Separating purely semantic taxonomies from the structures used for delivery can allow for several transformations which may not be possible in systems not designed for taxonomy management. For instance, allowing for logical navigational hierarchies which don’t follow meaningful “is a” taxonomy building principles.

Separating taxonomies may not be necessary, however, if your taxonomy and ontology system, a transformation layer, or the consuming systems can filter or restructure taxonomy values into new hierarchies which are context appropriate. Following are several use cases I’ve heard which may require this kind of transformation.

A Little Bit of Everything from Everywhere

In this scenario, the consumer needs to combine many different types of concepts into a new, usually smaller taxonomy for use in tagging or navigation. For example, they want either individual concepts or branches from different and mutually exclusive domains recombined into a new, single taxonomy for something like a front-end or app experience. Keeping track of all these different values when potentially scattered across numerous taxonomies at different hierarchical depths can be very difficult for taxonomists to visualize and maintain. In essence, they need to see a deliverable sub-taxonomy within the larger taxonomies they have created.

One way to solve this is to use skos:Collection as a label which can be applied to individual or hierarchical concepts in order to group them for delivery. SKOS collections support grouping, but they don’t support hierarchy, so the delivered concepts may be presented as flat lists in dropdown or typeahead fields. Often, the retention of hierarchy loses meaning when consumed from collections anyway as the collection label can theoretically be applied to any concept at any level, making the retention of hierarchy difficult or even nonsensical.

Adults Only!

Another fairly common use case is the consumer needing parent terms but not the children. Or, just as common, some but not all of the children or selected children at different levels of the hierarchy for a skipped-level hierarchical delivery.

In this scenario, it could be possible to use a designated property for each use case if the taxonomy management system APIs allows for filtering by a property or relationship. A property will likely be a Boolean flag to indicate it is either true or false for a use case delivery and end consumers can choose to filter out all Boolean values set to false. A relationship could be associative or hierarchical in order to create a hierarchy in which a parent has one set of children for one broader/narrower relationship and another set of children for another broader/narrower relationship.

The downsides to both of these solutions is both maintenance and functional feasibility. Can taxonomists develop and maintain properties and relationships for each different use case and make sense of them in the UI? Can the taxonomy tool represent hierarchies in which one parent term has different child terms with different broader/narrower relationships, especially if the hierarchical parent-child chain is a mixture of different broader/narrower relationships? In these cases, an associative relationship which stands in place of the broader/narrower relationship may work better in the system even if it doesn’t feed the concepts as parent-child to consuming systems.

Call Security!

What about concepts which need to be delivered to internal consumers but not to external consumers or partner organizations? In this use case, there may be much more at stake than user experience and presentation. If the wrong values are delivered to the wrong customers, there could be legal ramifications or new product releases could be leaked ahead of schedule. In this case, using a Boolean flag may enforce what values are sent to which consumers. Similarly, a status field in the system may be even better. Concepts in a “candidate” status should never be published to downstream systems until they go through a workflow in which they move through stages like “reviewed”, “approved”, and “published”. Similarly, having a “deprecated” flag or status can keep concepts which should no longer be used from flowing downstream to systems in which they can be tagged to assets or exposed in user experiences.

I Know You Are but What Am I?

Probably one of the most common delivery use cases is the “everybody is special” problem. In this case, consumers are steadfast in their ambiguous use of a concept and that its meaning must mean different things to different people depending on the context. In good taxonomy practice, we would opt to disambiguate homographs or other contextually dependent concepts. For example, “mercury (metal)”, “mercury (planet)”, “Mercury (god)”, etc. For navigational purposes, users won’t want to see these qualifiers as we use them in taxonomy practice. In these cases, context frequently provides the meaning needed at the time. If we go to a website and search for or choose “Brazil” as a location, this means the country. If we go to a website and search for or choose “Brazil” as a filter during World Cup, we mean the Brazil National Football Team. If your taxonomies cannot separate “Brazil (country)” and “Brazil (football team)”, this built-in ambiguity is going to cause major problems across your internal data systems.

If the system functionality permits, using proper taxonomy practices and disambiguating concepts in the semantic taxonomies and then stripping off these parenthetical qualifiers based on use case can maintain both meanings while allowing for front-end ambiguity. Each term will have its own full label and, more importantly, URI, to tell us which was the country and which was the team. Ideally, the taxonomists may be able to influence internal business requesters in a direction which will not require this. “Brazil” is a country only and “Brazil National Football Team” is a football team only. But practitioners know it’s not that easy. We can either allow the ambiguity and deal with the consequences later or we can get clever about filtering taxonomies so we can deliver the concept consumers want without sacrificing the semantics behind the scenes.

In my experience, which may be limited by the tools I’ve used and the organizations at which I’ve worked, having the ability to create this amount of taxonomy restructuring flexibility can be very difficult with a taxonomy management system alone and requires negotiations with intermediary transformation layers or consuming system owners to build out the functionality to enable more flexibility and scalability in taxonomy modeling.