Home » taxonomy (Page 2)
Category Archives: taxonomy
Modeling a Moving Target
“Like a wave in the physical world, in the infinite ocean of the medium which pervades all, so in the world of organisms, in life, an impulse started proceeds onward, at times, may be, with the speed of light, at times, again, so slowly that for ages and ages it seems to stay, passing through processes of a complexity inconceivable to men, but in all its forms, in all its stages, its energy ever and ever integrally present.” – Nikola Tesla
Some of the most thorough, authoritative, and well-constructed controlled vocabularies have been built and curated over the course of decades. The NASA Thesaurus was first published in 1967. The Library of Congress Subject Headings can be traced back to its roots in 1898. The MLA Thesaurus was modernized in 1981 based on previous classification methods. The Getty Art & Architecture Thesaurus was started in the late 1970s. There are many more examples of well-established controlled vocabularies, some older and some newer.Maybe there’s something to the adage “with age comes wisdom” in the longevity and authority of these vocabularies.
Many of these longstanding vocabularies serve the academic system and do not necessarily “move with the speed of business”. In a business environment, the emphasis is typically on speed, agility, and efficiency. None of these qualities are in opposition to the typical development of good controlled vocabularies, but a fast-paced organizational environment can certainly be difficult to support with vocabulary development that can’t keep up.
In my experience, product vendors talk about how to speed up taxonomy and ontology development while semantic practitioners (librarians, taxonomists, ontologists, etc.) regularly have to strike a balance between maintaining quality semantic models and serving the business needs. The speed at which semantic models need to be developed in a business setting often leads to the extension of inappropriate taxonomy use cases in order to support and facilitate immediate business priorities. We need to step back and ask ourselves how we can as taxonomists effectively support the business while addressing what should be modeled in taxonomies and what should not.
In this blog, I’m going to focus on two closely related cases of data which I think are not appropriately modeled or maintained in a semantic model but are often brought up as examples of serving the business quickly.
Processes & Sequences
A business problem I’ve seen in my roles as a taxonomy management platform product manager for a vendor and as a taxonomy practitioner is the modeling of processes as taxonomies.
There are several difficulties with modeling processes as taxonomies, and why I tend to discourage their inclusion as part of the overall enterprise taxonomy and ontology semantic framework. First, steps in a process aren’t usually semantically hierarchical. For example, say you are asked to support a step-by-step process for submitting a ticket in a request tool such as those offered by ServiceNow or Atlassian in a centralized taxonomy. An IT service ticket can be opened, assigned, reassigned, resolved, closed, and reopened. Building these steps as a hierarchical taxonomy doesn’t convey their true relationship to each other. You can build these steps as a flat list, which addresses that problem, but then you have a sorting issue of making sure the steps are displayed in the proper order in the consuming system. Since the actual ticket requests live in a consuming ticketing system while the controlled values naming each step in the process live in a taxonomy management system, this may not be a problem at all. The ticket is an object that is simply tagged with a new value at each stage in its lifecycle, regardless of the flat or hierarchical structure in the taxonomy. So, the first problem may be solvable, but it needs to be addressed.
The second issue is that processes are rarely progressive steps from beginning to end. The stages of a ticket may move up and down a flat list or hierarchy, often skipping steps in between and moving back to a previous step. Again, if the ticket is tagged from a flat list which is properly ordered for display, this may not be an issue. If the consuming system must follow the flat list or tree order, however, there may be challenges in changing the value to a previous step. Where this gets complicated, however, are processes in which the same steps are repeated by different groups in the organization. A contract, for example, can go through contract review by the vendor, by the business team representatives, by legal, and again by the vendor’s legal. Modeling a process like this taxonomically often means that these repeated processes are either appended with the team or entity conducting the process step (business review, legal review, etc.) or repeating the steps as children under organizational group headings, creating a polyhierarchical nightmare.
The final and most difficult challenge with modeling a process is that they often change. In another example, modeling the customer journey from start to finish is much like stages in an IT ticketing process. The customer rarely moves neatly from each step to the next. More importantly, however, is that marketing processes frequently are overhauled with changing values anytime there are changes in business strategy. Even when the values don’t change, their ordering of the process does and these orders are often reflected as navigational structures represented as filters on the front end. Representing a customer journey based on filterable values is challenging because of the numerous ways a customer may enter the UX pipeline. In retail apparel, for example, they may start looking for products at Gender (Men’s, Women’s, Children), then apparel type, then size, then filtering by material or color. Or, the customer may start with color, then apparel type, then size. There is a process here, but one with multiple entry and end points. Trying to represent this as a taxonomy is incredibly difficult.
A similar problem I’ve come across in taxonomy modeling is using lists or hierarchies to indicate sequence. Most processes have steps that are in sequence, but in this case I’m talking about strictly fixed sequential order. Examples can include the order of books or films (by date or by narrative order), the list of U.S. Presidents in order, or events by date.
The fundamental issue for most taxonomy management systems, and for many systems relying on taxonomy data for that matter, is the default to alphabetical display in lists. For most taxonomy hierarchies, alphabetical is the preferred display order, with each cascading branch also alphabetized. On most front end websites, navigational taxonomies are ordered by use with the most prevalent ways to access information listed first. Front end website platforms are built for this type of information display because the hierarchies do not necessarily follow what I would call semantic or “is a” taxonomy practices; parent child relationships are based on filtered drilldowns, not by strict contextual meaning. Where this becomes an issue is when an organization, quite rightly, wants to consume centralized taxonomy concepts for the front end experience.
Even when using the larger graph underlying taxonomy and ontology structures, conveying order can be challenging without the right functionality to support it or the ability to leverage the model in consuming systems that can only handle flat lists or shallow hierarchies.
Modeling Options
Modeling sequences isn’t out of the question in taxonomy management systems assuming that 1) the taxonomy and ontology management system includes functionality supporting modeling options, or 2) downstream systems can effectively handle or transform concepts received from a centralized taxonomy.
To model steps in a process or to capture sequences, there are a few options. If you are using a tool supporting RDF and core SKOS elements, you can consider using skos:OrderedCollection. An ordered collection is exactly what it sounds like: a collection of concepts put in a specified order. Using an ordered collection for a list of concepts in a branch of taxonomy allows listing those items in the order desired. There may be no other indicators of why those concepts are in that order if stripped from their contextual parent, but it will force sort a group of concepts. This assumes, of course, that the consuming systems don’t simply revert to alphabetical order once received.
A more flexible and sustainable way to model a process is to model semantically using “is a” rules and then leveraging a true ontological structure and a graph to map the journey. This means modeling concepts in their one best location in one or more taxonomies as part of a larger domain model. Modeling this way leans into the strengths of an ontology by using associative relationships between entities to make a graphical representation of the order while also connecting the entities to their owners. So, for example, books or films may have relationships like is followed by / is preceded by and then can be connected to their authors, directors, and actors as part of a greater graph.
Another option is to include a property on each concept. The property could be a field which indicates a numerical value listing its placement in the list. While this metadata field could be useful in the taxonomy user experience, whether or not these property values could be used in consuming systems to order items is still problematic. Furthermore, it gets complicated if it’s necessary to order multiple sets, all of them including the same numbers as an ordering property.
In advanced graph-based taxonomy and ontology management systems, there may be an option to use reification or RDF* to support metadata on triples. In this way, the ordering is embedded on the edges themselves. For example, books and films could include relationships with a release date. This could look something like “James Bond film” has release date [20061117] “Casino Royale” in addition to a broader/narrower relationship between the two concepts. There are several modeling options to make use of associative relationships with added metadata on the relationship edge.
In sum, it’s not impossible to model processes and sequences in taxonomies, but it requires thoughtful modeling in the context of other existing business taxonomies likely sharing the same overarching business ontology. Moreover, thoughtful modeling may not move with the speed at which an organization wants to move, but slowing down and getting it right the first time can save a lot of painful rework later.
Taxonomy Calling
“Hello, is it me you’re looking for? / ‘Cause I wonder where you are / And I wonder what you do / Are you somewhere feeling lonely?” – Lionel Richie, Hello
One of the most challenging activities in taxonomy work is communicating the value of taxonomy to potential business stakeholders. With so many shiny, promising technologies and methodologies, it can be daunting for the taxonomy strategist to win over converts to taxonomy use. Taxonomies and their applications are often misunderstood or are narrowly focused on a few common use cases like navigation. While business users can clearly articulate their needs, they may not be able to connect those needs to how taxonomies can be applied in the business.
The taxonomy strategist must be able to communicate the value of taxonomy while expressing the complexity of semantic structures like ontologies and their supporting technologies simply and succinctly to a variety of business stakeholders.
Communicating the Value through Examples
To gain taxonomy users, it’s essential to communicate the value of taxonomy. One way to start is to seek out areas taxonomy can directly address, find examples of the current state problems, provide taxonomy-based solutions, and then communicate the findings to the business owners. This process can be initiated by the taxonomy strategist or by the business owners themselves, assuming, of course, they know to contact the taxonomy team in an effort to answer their need.
One simple, powerful example is to review a search-dependent organizational website–which could be an internal intranet or external, public-facing website–and collect examples of navigational and search barriers causing confusion, poor search results, or revenue-losing scenarios. For each example, provide an explanation of how taxonomy might help. For navigational issues, the taxonomy solution may be category restructuring or improved, facet-based results filtering aligned to the typical user journey. For search retrieval issues, taxonomy may be used for typeahead search keyword matching or to improve search relevance to include more accurate or additional results through content tagging or keywording. Navigation and search are often close to time-saving or profit-driving activities, improving the efficiency and bottom line of the organization. Search examples and their potential taxonomy solutions, therefore, are closer to the source of organizational revenue and make convincing use cases.
As generative AI becomes more prevalent in organizations, finding examples of general or inaccurate results and how an enterprise, domain-specific taxonomy (and ontology) can act as foundational training data to improve those results can result in convincing proof of concept projects. Generative AI and machine learning models can seem like magic to the average user who may not know the amount of time and data it takes to train a model to produce accurate and useful results. Providing examples of poor machine learning model output can illuminate the need for clean, accurate foundational data. As an organizational source of truth, taxonomies can provide such semantic data.
To overcome user confusion about what taxonomy means or clarify what they think taxonomy means, try starting with the end result and work backwards. When assessing the value of a new bathroom faucet, someone will look at whether the fixtures look appealing and if hot and cold water comes out as expected. Initially, no one is interested in the pipes. Taxonomy, unflatteringly, is the pipeline infrastructure providing clean water to downstream consuming systems. First show excellent search results or machine learning outcomes and then explain how taxonomy is the basis for those results. If business stakeholders are interested in taxonomy, all the better for your work and evangelization. If they aren’t, let them be impressed by the final state and develop a process of working together to get to and maintain that final result.
Communicating the Value through Time and ROI
One potential stakeholder hesitation may be the time it takes to perform discovery, conduct the build, and put taxonomy values into production. This process can take time in the initial business stakeholder relationship. Once established, however, the speed at which business users can request concepts and see them live can move as quickly as your organizational systems can handle. People often believe they need to “move at the speed of business”, which, ironically, they think is fast but is more often cumbersome, manual, and slow. What they want is the magical now in which thought is converted to action faster than Captain Kirk can have his shirt ripped when first confronting an alien species.
Machine learning techniques, once perfected, can offer the kind of rapid response business owners are looking for, but only after a lot of training. Specifically, a lot of training on assets and data tagged with taxonomy. Too often, the “magic” of artificial intelligence business users are sold isn’t artificial at all: it is thousands of hours of tagging content and training models to get the desired results. If done properly, there’s nothing wrong with using machine learning models to quickly react to trending topics or generate text on the fly. However, the slower growth of a taxonomy, as I cover in my blog The Taxonomy Tortoise and the ML Hare, actually creates speed in other areas, saving time in responding to consumers’ direct search queries and tagging content to train and evolve machine learning models. Communicating the need for time investment up front to generate time-savings later can be compelling.
Communicating taxonomy ROI, which I covered a few years ago in my blog for Synaptica, Running a Successful Taxonomy Campaign, can be extremely difficult. How do you explain how words become money? Again, show the examples. Mining successful and failed search results and mapping these to taxonomy as metadata tagged to assets can show a direct line between creating taxonomy concepts, applying them to content, and successful search results that end in a product purchase. Going back to time, time is money: time employees spend manually creating, tagging, and manipulating content which drives sales; time spent training machine learning models; time spent seeking information which has not been tagged with metadata. Ramping up taxonomy processes to more quickly tag content and put words into production will result in quicker time to money and realized ROI. While starting taxonomies can be slow at first, the more success the taxonomy strategist has in engaging business users, the more quickly the taxonomy is built out and covers the breadth needed to tag assets and express important concepts users are seeking.
Communicating Complexity
Communicating the nuance and complexity of taxonomies and ontologies may be necessary as the details of a pending or ongoing project develop. Few business contacts need to know the difference between a flat list, taxonomy, thesauri, or ontology. In fact, I find there are disagreements about the differences even among practitioners. That said, users can come to the discussion believing that taxonomies are only hierarchical lists of terms. For most practical discussions, I use the term “taxonomy” to include flat and hierarchical lists of terms, properties, and hierarchical and associative relationships. I rarely bother with ontology concepts like classes unless they are necessary to meet the project objectives.
If these terms do need clarification, however, I often clarify with simplicity. Taxonomies are concepts (preferred labels) that include synonyms (alternative labels) and other metadata attributes (properties) and these concepts can be related hierarchically and through custom relationships (associative relationships). When discussing ontology, I usually state that taxonomies are the words you want to use and the ontology includes the rules for the words you want to use. For example, how concepts are grouped (classes), how they can be related to each other (domain and range constrained by classes), and whether certain properties can be made available for a use case (properties constrained by classes). That’s often all a user needs to know.
There are more advanced use cases, like machine learning, which is, in my experience, more of a mapping of ideas than an education. Data scientists usually use all the same concepts as taxonomies and ontologies but may use different terms to express them. After one or two conversations, the mappings are understood and the complexity is simplified. It’s not often a data scientist needs convincing to leverage taxonomies, but getting on the same page with conceptual ideas is a good way to make taxonomy value clear.
In large organizations, there is usually information architecture complexity as well. Because of this, taxonomy can often become necessarily complex as values are consumed by and flow through various systems. Understanding this workflow is not always a prerequisite for understanding the value of taxonomy, however, and does not need to weigh down conversations with potential business stakeholders. If it does become necessary, simplify those information architecture diagrams into simple flowcharts between systems, showing at a high level how taxonomy concepts move from system to system and what they do in each.
Being a taxonomy strategist is challenging, but is a necessary part of the job for taxonomy to show and prove its value in the organization.
The Taxonomy Tortoise and the ML Hare
“I knew I shoulda’ taken that left turn at Albuquerque.” – Bugs Bunny
For better or worse, much of my childhood was informed by Looney Tunes, Monty Python, and a diet of science fiction ranging from the profound to the disjointedly camp. As such, I expect the absurd and am wildly skeptical of easy answers. Additionally, my foundation of science fiction books and films compels me to speculate that artificial intelligence will become a more realistic probability in our lives with actions ranging from locking us out of airlocks and starting global thermonuclear war to providing answers to our most pressing global problems.
The long-promised advantages of artificial intelligence seem finally to be reaching a point at which they can be utilized for enterprise purposes, including parsing, and even understanding, large amounts of text and data at rapid speed. The recent successes beg the question that if machine learning models can operate on data at high volume and velocity, then why shouldn’t they be used to come up with answers on the fly based on large amounts of data internal or external to an organization? Well, in fact, they already are, and, in my opinion, they should, but not without some acknowledgment of absurdity and a certain degree of skepticism.
I’m a firm believer in defining semantic models in the form of taxonomies and ontologies to be used as a foundational schema for an organization’s data. One of the arguments against investment in taxonomies is the time it takes to create them and the amount of maintenance they require to sustain them. In a world in which what is trending changes frequently, user tastes are fickle, and the jargon associated with these trends passes quickly, the desire to avoid the tortoise-like pace of building taxonomies in lieu of utilizing other, faster technologies is tempting. But, as the hare who lost the race to the tortoise laments, “I knew I shoulda’ taken that left turn at Albuquerque.” Or, let’s consider checking the map before we go racing off in the wrong direction.
Let’s talk semantics. Putting it simply, ontologies are semantic structures which define one or more domains. They describe the types of things in the domain (classes), how these things can relate to each other (relationships, predicates, or edges), what labeled fields are used to describe these things (properties), and the instances of things (subjects, objects, or, more plainly, taxonomy concepts). Ontologies describing the general domain and taxonomies including the specific instances within one or more domains can be created as a map of your organization. These semantic structures represent the organization in all of its complexity. They specify the concepts important to the company and how these concepts relate to each other, data, and content. Once data or content is added, we can call this entire structure a knowledge graph.
In short, ontologies, taxonomies, and content are the organization’s view of itself, the world, and where it lives in it.
Large language models (LLMs) have the ability to generate text, answer natural language questions, and classify content. Most publicly available LLMs, like ChatGPT, are trained on publicly available information. It is also possible to supply these LLMs with your own training sets of documents and language samples to develop answers more applicable to your own organization. Wisely, many organizations tightly control what information can be presented to these AI tools to avoid company information leaks or supplying competitors with proprietary information.
What’s lacking in using these hare-rapid models, however, is the organizational perspective. They are very good at answering general questions and making factual assertions from text, but they require tailored training content with specific use cases in mind to generate answers specific to an organization’s needs. There can be a temptation to feed one of these models a large quantity of organizational content to train them faster. However, the span of topics, language, jargon, and acronyms used in an organization can yield unsatisfying or unpredictable results. Imagine, if you will, the amount and variety of content in any one of your company’s content management systems. Now imagine asking a machine learning model to analyze and make sense of it all without guidance. You can index all of your own content, but without a framework, what sense does it make?
At this moment, the hare and the tortoise must strike a deal if they both want to win. To improve the performance of LLMs and other machine learning models, a domain topology specific to your organization defining the concepts, their synonyms and acronyms, and how they relate to each other, can be used as a schema input into the model. Semantic models are, after all, assertions in the form of triple statements (subject-predicate-object). Ontologies establish factual statements as determined by your organization’s use cases and, hence, provide patterns which can be used by machine learning models. Lexical proximity can be gathered from taxonomy hierarchies (these concepts are more closely related because they share a parent-child relationship) and associative relationships (these concepts, separated across several taxonomies, are actually very closely related because they have a direct associative relationship between them). Semantic models provide factual statements, built slowly over time based on business use cases, which can augment and improve LLMs.
Not only can we think of semantic models as a collection of factual statements according to your organizational domain and use cases, we can also think of it as a summary, requiring the LLM ingest a lot less information to reach the same factual conclusion. For example, you can provide the model with a huge amount of training data stating that a particular SKU-level product is available in the color blue. If this is a factual assertion in your semantic models (Product name has color Blue), however, then this fact can be tagged to a single product representation in a database and in turn is applied to thousands of real-world SKU instances. Semantic models are a distilling and modeling of thousands of instances of truths across an organization and summarized into a collection of ontology structural elements and taxonomic instances. Citing a joke by Steven Wright, in which the comic tells us he has a map of the United States which is actual size, your organizational map can be represented in a much smaller scale.
Yes, it’s certainly true that given large amounts of data, machine learning models or text analytics can identify all kinds of important concepts. These concepts (and fact assertions between concepts) can be a great pipeline to feed into taxonomy and ontology construction. I am skeptical of machine learning models generating taxonomies and ontologies based on organizational data and content unless there is heavy human-in-the-loop curation to reconcile those absurdities which I believe inevitably creep in. And, yes, it’s certainly true that this curation is potentially at a tortoise pace, but once these concepts and assertions are built into semantic models, the ongoing maintenance and governance demands less time and effort.
Those slow semantic model builds enable fast-moving machine learning models and LLMs to be grounded in organizational truths, allowing for expansion, augmentation, and question-answering at a much faster pace but backed with foundational truths as asserted by your organization.
Be the tortoise first and foremost and the hare will follow.
Semantics and Risk
“There are no facts, only interpretations.” – Friedrich Nietzsche
Behind every creation–a work of art, musical composition, outstanding sporting performance–there is a creator. Behind a creator’s creation are copyright laws and license agreements detailing how that creation can be bought, sold, represented, and reused. In retail, the works and likenesses of artists and creators appear on merchandise which may be globally distributed. Whether it is the recognizable Jordan Jumpman icon or Bob Marley’s face on a t-shirt, there are contractual obligations and regulations which must be followed to avoid risk and exposure for both the creator and the contracting company. The use of names, images, and likenesses is captured in contractual language, defining the way an image or other work can be used and providing the legal foundations to make sure royalties are paid to the artist and their representative company.
In many organizations that have arrangements with artists or athletes, there are dedicated systems to manage contract documents specially designed to handle the content and also apply the appropriate type of metadata to describe these assets. The digital assets protected by these contracts, such as works of art, images, video, audio, and the like, can be stored in a digital asset management (DAM) system, which specializes in maintaining technical, administrative, structural, descriptive, preservation, usage, and rights metadata. In digital visual works, these rights and permissions may be captured as rights metadata accompanying the image file. Similarly, audio works can carry this information on physical media, and, more commonly, embedded in the individual audio files and the bound collection of an album. Rights and permissions are thus often associated to the artistic creation in both physical and electronic formats.
The metadata to populate values in these platforms can be created and maintained in a taxonomy management system to ensure the application of consistent values in one or more consuming systems. Taxonomies can contain centralized, standardized values describing asset usage and rights and can also provide descriptive metadata values; that is, the metadata that describes what the content is about or what is represented in it. In the world of semantic technologies, taxonomies and ontologies model domains to provide meaning which can otherwise be lost when flattening or decontextualizing metadata attributes. Since taxonomy and ontology management systems were not designed to be content or digital asset management systems, the taxonomy values and the ontology structures which define their use can potentially become detached from the content they describe. The semantic model lives in one system for application across one or more consuming applications while the objects themselves live in those systems, likely containing a mix of system-specific metadata, like technical descriptions of asset size and format and descriptive metadata coming from a taxonomy.
Semantic modeling is an act of establishing veracity. Taxonomies and ontologies model the domains of the organization, including describing the concepts in taxonomies and the relationships between them. Agreeing on what preferred label form to use, which concepts are synonyms, and establishing hierarchical and associative relationships between concepts are all actions to model the truth; or, more accurately, your truth based on the knowledge domain and how it will be used. For instance, modeling fixed relationships between an authority file of athlete names and associated taxonomy concepts could have the following named entities:
Athlete name has team Team name
Athlete name has product Product name
Team name has geography Geographical location
Each of these statements asserts a truth between one or more concepts at any given time. When that truth changes, but the model doesn’t change to reflect it, there is a drift between the current legal standing stated in contracts and how this is represented in the organization’s schema. When creative works or artist likenesses are surfaced on a front end user experience, such as linking a search term to a product or presenting audio or video content in a streaming service, the assumption is that the party responsible for the platform is presenting content for which it is legally liable.
Ironically, the attempt to standardize taxonomy values and their relationships for application across different systems to mitigate the risk of inaccurate metadata values being applied to content and to drive functionality like search and personalized recommendations can in fact introduce new risks. When defining the organization’s domains, it is important to bear in mind how that schema is applied to the actual “things” in other systems and what modeling a full domain truth might mean for how those assets are discovered and used. Attempts to model accurately and truthfully, when applied to content, can inadvertently reveal or persist truths which should not be exposed or have changed meaning over time.
For example, selling athlete merchandise associated with a team is common practice, since fans support teams and the athletes who play for those teams. However, facts which seem immutable, like team names and rosters, can change over time. I live in Oakland, California, home of the Raiders. Well, former home of the Raiders, who are the Las Vegas Raiders who were the Oakland Raiders who were the Los Angeles Raiders who were the Oakland Raiders. How many Raiders players have come and gone over the years and have played for multiple teams throughout their careers? Keeping on top of this kind of high-velocity data changing at scale can be extremely difficult. The same can be said of company-sponsored athletes. Contracts change and products once associated to or endorsed by an athlete may no longer be associated to that athlete. Selling one of these products out of contract can have serious financial and reputational repercussions.
Taxonomy and ontology governance processes must be firmly established and followed in order to make it possible to represent the company domain accurately while mitigating risk. A tight working relationship between the taxonomy team and business representatives in legal and/or marketing is a first priority. Whenever a contract changes, a request must be submitted to reflect this change in the semantic models so tagging moving forward is accurate. Changes to semantic modeling to reflect the new truth doesn’t only happen in the taxonomy management system. The change must be propagated to consuming systems and content on a known schedule. If the change is immediate, the tagging must be changed immediately. If the change goes into effect on a given date or at the end of an established period, the change must be made and pushed to meet that date.
Changing available concepts and tagging practices from a fixed point moving forward is relatively easy compared to other requirements, which may include the untagging or retagging of content to ensure it is not retrieved by search or otherwise discovered by consumers in the user experience. If an association between a team and an athlete is no longer valid, the company may have the opportunity to sell product through an established period of time, allowing the liquidation of as much outdated product stock as possible. After that time, however, discovering a product and purchasing it with the contract no longer being in effect can open the organization to significant risk.
The same risk applies to content not yet ready for prime-time. Any new product release, if tagged and made available to the user experience before a release date, can damage a company’s product launch and severely impact the time and planning that went into organizing an effective campaign. Internally, the risk still exists. If artist or product information is pre-planned in the organization’s metadata, there must be processes in place to keep this information known only to those who need to know it. That means allowing permissioned access to planned artist and product concepts to only those who need to know to avoid information leaks ahead of a release date. While organization’s have contracts stipulating how internal employees handle private company information, it is possible for a product release statement or other content to be discovered internally and intentionally or unintentionally shared to social media sources.
The examples I’ve provided here are in the domains of copyrighted work, but modeling against risk and exposure is even more critical in industries like medicine, health and safety, and manufacturing, just to name a few. While modeling truth is the ultimate goal of creating and curating semantic models, all concepts and their relationships which may be used to power a user experience, such as seeking prescription medicine or medical advice, safety procedures and equipment, and best practices in manufacturing, need to be carefully evaluated before being put into production in an application. While financial and reputational risks and penalties can be damaging, they pale in comparison to inappropriately modeled information people rely on to make potentially life and death decisions.
True to their name, semantic models are meant to be meaningful and act as a source of truth. Actively maintaining taxonomies and ontologies to be in line with truth as it changes includes a vital set of governance processes which must be carefully planned and executed to ensure the company is not exposed to risk. Unfortunately, there may be domains which can’t be modeled in taxonomies because the supporting processes don’t exist or can’t be maintained and executed upon efficiently enough to demonstrate low risk. If these domain areas are important to the organization, a strong case must be made to establish and maintain the processes and resources necessary to exploit beneficial modeling before the company is put at risk in the first place. An organization might not view semantic models as a potential source of risk, so it is up to semantic architects, taxonomists and ontologists, to be conscious of modeling repercussions and actively pursue governance processes to ensure their work is an accurate and up to date source of truth.
Polyhierarchy and the Dissolution of Meaning
“Everything is everything/What is meant to be, will be.” – Lauryn Hill
Polyhierarchy
Polyhierarchy is “a controlled vocabulary structure in which some terms belong to more than one hierarchy. For example, rose might be a narrower term under both flowers and perennials in a horticulture vocabulary” (ANSI/NISO Z39.19-2005 (R2010), Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies).
While the ANSI/NISO Z39.19-2005 (R2010) standard is still my go-to for foundational taxonomy principles and may provide validation for using concepts in more than one location, I try to avoid polyhierarchy as much as possible. I see it as a construct necessary only in rare situations and because many systems are unable to consume taxonomical concepts in any other way than their actual location in a hierarchy. Specifically, I don’t like polyhierarchy which is 1) abused out of necessity to suit use cases consuming systems can not otherwise meet, or 2) used to solve many, differing use cases. To me, polyhierarchy is the enemy of specificity; it is the forward slash of the taxonomy world…the imprecision and indecision of the either/or.
There is a conflict between the construction of one or more taxonomies for semantic accuracy and how those taxonomies are displayed because of the inability to transform and restructure taxonomies to meet different, real-world use cases. If the use case demands a concept be more than one thing in more than one place, it must be put in all of those locations in the originating taxonomies to suit navigational needs.
My former colleague and contemporary taxonomy practitioner, Bob Kasenchak, wrote in his blog post “On Polyhierarchy”, “The most common misuse of polyhierarchy is overuse: the tendency to give terms multiple parents without sufficient reason.” I agree. This statement gets to my main objection with polyhierarchy in that when it is overused, semantic precision is diluted. When everything is everything, nothing is anything.
Polyhierarchy in Navigational and Information Access Taxonomies
People have different ways of searching for information and, in an online world in which a user can start in any number of locations and expect to get to the information they want, polyhierarchical taxonomies facilitate navigating to information through multiple pathways.
A common and familiar use case for polyhierarchy is in navigational taxonomies used in online retail. Consumers may require multiple entry points in product hierarchies to find what they are looking for. Using a search engine to get to a product display page in the first place is a common scenario in findability, while searching directly on the retailer’s website is often a consumer’s next choice. However, once on a website, users may use navigational structures and filters to get to specific products. Even if the navigational browse taxonomy is displayed as a flat list rather than a hierarchy, having multiple points of entry is going to lead consumers to the product they are seeking.
For example, one might expect to find Basketball shoes under Men, Women, Unisex, AND Kids. One may also expect to find Basketball shoes under Sports > Basketball. Given the current trends in athleisure apparel, one might also expect to locate Basketball shoes under Casual or Lifestyle. These divergences in meaning account for both a consumer’s individual browsing paths and competing notions of what Basketball shoes are worn to do. For a consumer, Basketball shoes may be just as easily in one category as another without any conflicting meanings.
Supporting this use case in one or more back end systems powering a front end experience may demand a concept be placed in more than one location in a taxonomy management system because the downstream system(s) can only consume concepts exactly as they appear in a hierarchy. In this scenario, you are forced to set up taxonomies that look like the following:
Kids’ shoes
Basketball shoes
Men’s shoes
Basketball shoes
Unisex shoes
Basketball shoes
Women’s shoes
Basketball shoes
Sports
Basketball
Basketball shoes
In the Basketball shoes example, the concept isn’t inherently a member of all the locations it is listed, but is listed in all locations as a way to facilitate user access to products through navigation. Even in this oversimplified taxonomy model, the repetition of the concept is becoming unwieldy.
Sometimes products really are two different things which can’t, or shouldn’t, be reconciled. The Z39 provides the example that a piano is both a percussion and stringed instrument. Therefore, on a website which sells many kinds of musical instruments, listing pianos under both seems sensible. Similarly, for a retailer selling toasters, ovens, and toaster ovens, we might expect to see Toaster ovens listed under concepts like Ovens and Countertop appliances.
The same principle applies when accessing informational content. For example, a country can be a part of a continent and a designated geographical region including more than one continent. For example, Denmark is both a part of Europe and EMEA (Europe, Middle East, and Africa). In a hierarchy, the construction may look like this:
Continents
Europe
Denmark
Geographical Regions
EMEA
Denmark
These use cases illustrate a need for polyhierarchy even in cases in which the back end systems may not support the need well.
Polyhierarchy in Semantic Taxonomies
Taxonomies which adhere to more stringent guidelines, which I will term semantic taxonomies, are those which follow taxonomy construction and maintenance standards in an attempt to arrive at more regular, logical structures to reduce or eliminate ambiguity. Building logical, semantic taxonomies have several long-term advantages.
First, adhering to simple principles of placing a concept in its single best location mitigates problems with system interoperability. In some cases, downstream systems consuming from a taxonomy management system can only recognize a single instance of a concept, most likely because it doesn’t have the ability to reconcile a label name with exactly the same string of characters. Another potential issue is consuming systems won’t allow for a concept with any label to have the same GUID to exist in more than one location. In well-structured semantic models, any polyhierarchical concept should only have one GUID or URI and not be a unique instance with exactly the same label but different identifier in each location. In this situation, the system receives the above example taxonomy hierarchy Kids’ shoes > Basketball shoes first on import and ignores each subsequent instance as it reconciles matching label strings.
Second, maintaining models requiring many polyhierarchical concepts becomes more difficult as more instances, and more semantically different domains, are covered by the taxonomies. Using the same form for a concept label with a single URI or GUID for multiple purposes can eventually cause a maintenance breakdown in which the concept loses semantic precision and scope and appears in locations with different logical underpinnings, especially using relationships with unique semantic meanings.
Finally, building semantic taxonomies supports the root purpose of taxonomic structures and ontologies: to define concepts so they are unambiguous. My taxonomy 101 go-to is the “is a…” principle. As a fundamental premise, I reject that a concept in most cases can not be placed in one, single best location expressing its intrinsic meaning. Is a toaster an appliance? Yes. Is an oven an appliance? Yes. Based on this, it’s easy enough to put toasters and ovens in their place.
Polyhierarchy also has acceptable use in semantic taxonomies. A concept can truly be a member of two categories which are overlapping or mutually exclusive. Our Denmark example above is a case in which a concept is a member of two categories. A homograph, like Mercury, is an example of a concept which has several, mutually exclusive, meanings.
However, in both cases, there are modeling choices to avoid polyhierarchy but are dependent on having the right functionality available. If the taxonomy tool supports associative relationships and consuming systems can use both hierarchical and associative relationships, the modeling may include a semantically named relationship in place of a standard hierarchical relationship. The associative relationship is part of geographical region can be used to create a specific semantic relationship to the concept EMEA allowing Denmark to be a child of Europe but not of EMEA.
Continents
Europe
Denmark is part of geographical region EMEA
Geographical Regions
EMEA
In the Mercury example, the Z39 suggests the use of parenthetical qualifiers so the concept appears in mutually exclusive domains which may very well all appear in one thesaurus:
Planets
Mercury (planet)
Metals
Mercury (metal)
Space vehicles
Mercury (space vehicle)
One of the challenges, especially in retail taxonomy concepts, is that concepts are rarely a single term. Returning to our Toasters and Ovens example, the concept Toaster oven was intrinsically two concepts, not one, because we have introduced a pattern or stacking nouns (toaster + oven) to create a new, compound concept. Even more frequently, adjectives are modifying nouns to include more than one independent, atomic concept. For the concept Men’s basketball shoes, the pattern is gender + sport + product. Sticking with our notion of a semantic taxonomy, the three separate concepts can easily belong to three, mutually exclusive schemes covering Gender, Sports, and Products. When the new concept is created, it’s easy to see how concepts find polyhierarchical locations in different schemes to support navigation.
What a thing is versus what is used for can also be problematic and demands a shift in thinking. Or, rather, defining exactly the modeling approach used across a set of taxonomies to maintain consistent semantic principles. Again, I stick with what a thing is. My favorite example is James Bond’s exploding pen from GoldenEye. Is the pen a writing utensil? Yes. Is the pen a weapon? Well…in this case it is. In the narrow perspective of spycraft, perhaps a pen is a weapon, but it is not inherently a weapon. In the Bond universe, a pen could very well appear in a taxonomy of weapons, but, as above, there are concept form and modeling choices which would alleviate the confusion. Rather than Pen, would it not then be entered as Exploding pen? Similarly, Bond has used a Rocket pen and a Poison pen. Once we modify these concepts, they then can find themselves in one best place in a taxonomy of weapons.
Why consider alternate modeling practices to avoid polyhierarchy if the standards and tool functionality allow it? In addition to the two reasons noted in this section, there is planning for unknown domain expansions in attempts to future-proof taxonomies for additional, currently unknown use cases.
Polyhierarchy across a Graph
A fundamental problem in modeling taxonomies is trying to serve two masters by including both semantic structures following logical rules and the useful, though typically less semantically precise, structures required for navigation. By trying to model for both purposes, there are inevitable conflicts which cause compromises in structure and meaning.
Different types of polyhierarchical instances living in the same domain attempting to address conflicting use cases cause the hierarchical taxonomies and the ontologies which provide logical modeling practices for the overall graph to experience semantic drift. While the human mind can understand seeing Dog food as a narrower term for both Pet food and Dogs, a system can only accept the strings it is given.
Using inconsistent modeling practices, like using different types of hierarchical or associative relationships for the same concept, causes concepts to drift from tightly bound semantic meaning, structural context, and scope. As the meaning expands to address more use cases, the precision wanes. As I said earlier, when everything is everything, nothing is anything. In other words, concept meanings become less precise and eventually concepts shift to mean what they are, what they are used for, where they are located in a navigational taxonomy virtual folder structure, who owns the concept, and on and on. The meaning erodes.
So what? We can see the concept in context and figure out what the meaning is, right? So why bother being so tightly bound to the concept meaning. A good use case example is using taxonomies to build machine learning models. The imprecision of having Basketball shoes under multiple parents to provide specific paths for gender navigation while also having the concept nested under sports requires that the model must be trained to understand that a basketball shoe is not a sport but is used for the sport of basketball. The more connections a concept has to other concepts through hierarchical and associative relationships, the more imprecise it becomes across the graph. While hierarchical structures are useful, graphs are even more so, providing the logical underpinnings for machine learning models, knowledge graphs, recommendation systems, semantic search, etc. Precise meaning becomes more important with each use case.
Polyhierarchy isn’t necessarily to be forbidden in semantic structures, but I propose using it sparingly, when a concept has truly more than one meaning, and for semantic structures which can then be transformed to provide concepts in any hierarchical structure for consuming systems and navigational use.
Information Panopticon 