The Simplicity of SKOS Collections
“Our little lives get complicated / It’s a simple thing / Simple as a flower / And that’s a complicated thing.” – Love and Rockets, No New Tale to Tell
The W3C SKOS standard is defined as the
“Simple Knowledge Organization System (SKOS), a common data model for sharing and linking knowledge organization systems via the Web.
Many knowledge organization systems, such as thesauri, taxonomies, classification schemes and subject heading systems, share a similar structure, and are used in similar applications. SKOS captures much of this similarity and makes it explicit, to enable data and technology sharing across diverse applications.
The SKOS data model provides a standard, low-cost migration path for porting existing knowledge organization systems to the Semantic Web. SKOS also provides a lightweight, intuitive language for developing and sharing new knowledge organization systems. It may be used on its own, or in combination with formal knowledge representation languages such as the Web Ontology language (OWL).” (SKOS)
The SKOS data model defines common taxonomy components like concepts, schemes, labels, notations, properties, and relations. It also defines the class of skos:Collection, a simple and useful tool in managing and delivering taxonomies. From what little research I’ve done, there doesn’t seem to be a lot of discussion or commentary on the use of skos:Collection in practice, but I think it is a simple way to enable taxonomy delivery in the organization.
What Is skos:Collection?
According to the W3C standard, “SKOS concept collections are labeled and/or ordered groups of SKOS concepts” (SKOS). They are defined by the classes skos:Collection and skos:OrderedCollection which are both instances of owl:Class. Using these classes, it is possible to group concepts across one or more schemes and at different levels in a hierarchical taxonomy. Concepts grouped as skos:Collection are delivered as a flat list in default alphabetical order while concepts using the subclass skos:OrderedCollection can be grouped and delivered in a selected order.
To define what concepts are included in a collection class, SKOS uses skos:member and skos:memberList as instances of owl:ObjectProperty. Any concept can be a member of a collecxtion.
Interestingly, skos:Collection is disjoint with skos:Concept and skos:ConceptScheme. A disjoint class is a grouping sharing no common members or instances with another class. “Collection and Concept are regarded as disjoint, so that the relation definitions disallow a collection from being a mid-level node in a hierarchy of concepts” (ISKO). This means collections are not typically defined as concepts with URIs themselves, but as blank nodes. In addition, the concepts gathered within a collection are not placed within a hierarchy as part of the named collection.
Concepts in a collection are delivered in a flat list because their class is “disjoint from concepts. It is therefore impossible to use SKOS semantic relations to have a collection directly fit into a SKOS semantic network. In other words, grouping concepts into collections does not replace assertions about the concepts’ place in a concept scheme” (SKOS). Not only are semantic relations not included within the class, but there is the practical limitation of retaining broader and narrower relationships when concepts can potentially be added to a collection from any scheme at any level in the hierarchy. It is extremely difficult to reconstruct a hierarchy with any sense or accuracy if concept levels are absent or skipped.
Why Use Collections?
When I worked at Synaptica (now part of Squirro), the taxonomy and ontology management system, Graphite, included easily accessible ways to create named collections on the fly and manage the member concepts. In the implementation of collections in this tool, it was possible to name the collection and add and delete concepts as needed. Different collections could include concepts from any taxonomy schema managed within a project and from any hierarchical level. Different collections could include the same terms if desired. So, it was possible to designate a collection at a hierarchical level and include all the children under it or select concepts from any level in any taxonomy. The main use case for implementing collections in this was to create a grouping for delivery through the API to a field in a consuming system.
To illustrate, a Geography taxonomy could have long lists of countries and cities. However, a consuming system may have a field requiring only a list of countries in which the organization operated. Of course it would be possible to create a new grouping concept in the taxonomy called “Organization countries” or something similar. Then countries could be added to this new grouping header as well as retained in their original structure nested under continents or regions (assuming that were part of the Geography taxonomy). However, using a collection is a fast and easy way to keep the original taxonomies clean without redundant polyhierarchical structures and additional grouping headers. In this example, we are using collections to grab a subset of a mutually exclusive set of concepts.
Collections can also be a way to group concepts conceptually that may or may not live in a single hierarchical taxonomy branch or even within a single taxonomy scheme. For example, there are many points within a content management lifecycle ecosystem to manage the way information is presented to customers. Typically, gathering products on a landing page organized around a common principle is the work of the web content management system. Ideally, these products are already tagged with a variety of metadata including concepts managed in a taxonomy. Grouping products by a metadata value should be relatively easy within a WCM system but conceivably could be gathered in conceptual groupings using collections. For example, a grouping concept like “Back to school” is a temporal but repeatable way to group products across many types of taxonomic categories. Again, this is typically done in a WCM system but can also be done in the taxonomy source system if the grouping is stable and repeatable.
Additionally, end users often ask for processes to be modeled in taxonomies. While this is possible, it’s equally feasible to list the process steps in a more taxonomic hierarchy and then deliver them as an ordered collection in the proper step stages. This could be particularly useful when selecting a flat list of terms in a downstream system to indicate at which stage a process is in.
While collections may have a limited set of use cases, I have found the use of skos:Collection a relatively simple way to group concepts for delivery, especially when these groupings are external to the domain modeled by the taxonomies. Notions like print vs digital, internal vs external, and other conceptual models which are not inherent to the concepts themselves are additional groupings not readily modeled within taxonomies. I have not conducted a full audit of commercial off-the-shelf taxonomy tools and their expression of collections, but it is potentially a simple and useful tool for taxonomists working directly within a taxonomy UI to group concepts for delivery.
Documenting Taxonomy Decisions
“Indecision clouds my vision / No one listens” – Faith no More, Falling to Pieces
A foundational tenet of taxonomy work is documenting decisions, including what the decision was, when it was made, who is acting on the decision, and who is ultimately accountable. The W3C standards and most, if not all, commercial off the shelf taxonomy and ontology management systems provide support for this documentation. Similarly, most enterprises have mechanisms for tracing what was done, when, and by whom.
I have seen firsthand the repercussions when taxonomy decision-making is not recorded or is not easily accessible as reference. Decisions are revisited, rehashed, and even repeated over the course of months or years. Changes to the taxonomy may be questioned and structures reverted to previous iterations in the course of taxonomy revamps.
Taxonomy decisions provide important context, particularly as AI finds more use cases within the organization. Proper decision documentation will become more important to serve user queries and ongoing taxonomy governance.
Documenting Decisions in the Taxonomy
One of the core principles of the W3C standards for semantic models is interoperability. As a result, taxonomy and ontology management systems adhering to the standards support the creation of self-contained models which can move between systems and retain their cohesion. Within SKOS, the skos:editorialNote, skos:changeNote, or skos:historyNote serve as free-text properties which can be used by taxonomists to capture why a decision was made. Since these fields are free text, a standardized way to capture information can assist with the reading and understanding of the contents. For example, structuring the note like “YYYYMMDD: Note text. – taxonomist initials” is a way to bring some sort of standardization to the field contents.
Common to most software platforms, history logs document what was changed, when, and by whom. These can be very important records to show what was changed in a concept record. What these logs don’t capture, however, is why something was changed. Cross-referencing changes between a history log and taxonomist notes in a note field can create a complete picture of any changes to a concept within a taxonomy.
The advantages of these combined documentation is that they can travel with the semantic structure as a complete package. The interoperable standards allow for the structure and the history of the structure to be delivered together.
Documenting Decisions Outside the Taxonomy
Documenting changes and decisions outside of the taxonomy serves several practical purposes. One, the sanctioned documentation tools of the enterprise can be utilized as they were intended with a taxonomy focus. Two, a wider audience can review and understand taxonomy decisions. Three, proprietary tools and formats are less likely to become a documentation and continuity issue if decision-making is recorded in more than one location.
Requests of any nature in an organization can be handled within a change request tool. Using one of these existing enterprise tools as part of the taxonomy governance process for additions, changes, or deprecations in the taxonomy is an easy way to build out a request process. These same tools often support comment threads, documents, and history logs so that the process to arrive at a taxonomy decision is fully documented. To provide full cross-referencing, the change request ticket number or URL can be documented in the taxonomy editorial note and the taxonomy concept URI can in turn be documented in the change request tool.
Additionally, it is not common that a wider business audience has edit or even read access to a taxonomy management system. Therefore, they do not have a view into the change decision-making process. Documenting changes in a change request tool (which, again, not everyone but the requestor may have access to) is one way to expose the decision process. Linking or embedding these change requests into other document locations—a text document, wiki, or communication email—can make the taxonomy change process more transparent to a wider audience. When decisions are made behind closed doors, intentionally or not, they are open to questioning. Fully transparent and accessible documentation helps to mitigate interrogating past decisions.
Finally, recording decisions in multiple locations may seem redundant, but this kind of duplicative documentation can, as noted, serve multiple purposes and audiences. Decisions are documented in slightly different ways and exposed to different audiences, but all to the same effect of recording the process and making it available to current or future users.
Contextualizing Decisions
As context graphs gain traction as a way to provide additional information about decisions, it seems to me that duplicating decision records in the organization, but connecting them in a way that includes a common anchor (the concept URI, the change request URL or other identifier, or even the URL of another document—though these are more vulnerable to change), can provide a single query point for taxonomy changes over time with context. Being able to query one or more sources of taxonomy change documentation opens up the ability to address the questioning of previous decisions. More importantly, these queries can thwart potentially iterating previously made decisions to avoid painful taxonomy reworks.
If a context graph can access the semantic structure and note properties, the history logs, the change requests, and any unstructured documentation, then a full portrait of what change was made, when it was made, who made it, and why it was made can be more easily accessible. Rather than running reports or searching across systems, a context graph can be prompted to provide the full change history of one or more contexts quickly and easily, maybe even within the course of a meeting in which a taxonomy change decision is questioned.
Following up on my last blog about endless taxonomy iterations, documenting taxonomy-related decisions can circumvent revisiting previously made decisions or even reverting back to prior taxonomy structures. The seemingly never ending churn around taxonomy structures can result in mistrust of the process or the value of semantic models. Carefully documenting decisions in multiple locations strengthens the governance process and mitigates reinterrogating previous well-reasoned, implemented choices.
Taxonomy Obl(Iterations)
“Beware of allowing a tactless word, a rebuttal, a rejection to obliterate the whole sky” – Anaïs Nin, The Diary of Anaïs Nin
There is no better way to gain trust and buy-in for enterprise taxonomies than to iteratively develop vocabularies collaboratively with business stakeholders to meet their use cases. There is also no better way to lose trust and buy-in for enterprise taxonomies than endless iteration on taxonomy values as different business stakeholders representing new and diverse use cases push back on concept values accepted in previous reviews.
The success of enterprise taxonomies depends on acceptance and use by the business, particularly in the consuming systems required to do their jobs. If taxonomies can not meet the needs of the business, system owners may enable workarounds for metadata tagging and search needs, splintering metadata values across platforms and use cases. Developing centralized, enterprise-scale taxonomies is challenging, especially as consumers and use cases grow and diversify, but it is not impossible and enables consistency in domain thinking and for analytics.
How then do we work collaboratively with the business and technology product owners to ensure taxonomies meet business needs while avoiding an endless death-spiral of (obl)iterations?
Come Prepared
One of the fundamental skills taxonomists bring to the table is the ability to research. As the vast and nearly universally accessible repository of information that is the Internet has proven, especially since the advent of social media, having information available does not necessarily mean it is found or interpreted correctly. Taxonomists frequently have a background in academically-based research and information synthesis. They know how to apply rigorous critical thinking to information to develop individual taxonomy concept labels and larger ontological domain structures reflecting the nature of the business.
While a taxonomist should rely on input from organizational subject matter experts, they should also come prepared to meet the business with taxonomy concepts and structures reflecting the terminology and thinking of the business and the industry at large. Many taxonomists are generalists, not deeply ingrained in any one industry but instead applying their art as needed in any organizational domain. Their ability to research and learn from SMEs, organizational data and documents, and external sources, allows them to come prepared with suggested term forms based on real-world sources.
Coming prepared with taxonomy concepts, definitions, scope notes, and suggested properties and relationships can curb pushback from business users by establishing truth based on common taxonomy development principles.
Effective Project Management
There are often two scenarios for taxonomy development: the taxonomist is developing a new or refining existing taxonomies as part of a larger project (digital asset or content management, website redesign, Intranet search, etc.); or, the taxonomist is working solo or as part of a team on one or more projects to iteratively develop and expand existing taxonomies to meet ongoing needs. Whether taxonomy development is project-based or in the maintenance phase serving many projects and use cases, effective project management is essential to ensure endless iterative revision cycles don’t bog down progress.
In the first scenario, the taxonomist is not likely to also be the project manager. One or more project managers is tracking multiple project workstreams and checking in with the taxonomist to see their work is progressing and on schedule to meet milestone and deliverable dates. These project-based milestones are very effective at reducing the risk of endless taxonomy iterations by establishing hard timelines and dates for delivery. Effective project managers will keep the project on schedule and reduce obstacles to milestone deliverables. Where needed, they can intervene in bogged down processes by identifying and escalating the risk to the overall project.
In the second scenario, the taxonomist or a taxonomy manager leading a taxonomy team is effectively a project manager. They ensure taxonomy requests are handled in a timely way and the taxonomy values, or whole taxonomies, are delivered to support the projects as needed. What qualifies as a “project” may be loosely defined, such as search or product tagging which can be ongoing work, or a discrete project requiring taxonomy development or support. Like a project manager, the taxonomist needs to meet and enforce deadlines and identify and mitigate risks to meeting those deadlines. Taxonomists wear many hats, and project management is likely to be one of them.
Establish Taxonomy (and Beyond) Governance
Not having clearly defined governance processes for taxonomy work will confuse business stakeholders and cause misalignment with the rest of the enterprise depending on clear processes. Establishing clearly documented taxonomy governance, including how and where to request taxonomy work, service level agreements (SLAs) for taxonomy delivery, and ways of working on iterative taxonomy development, can enforce practices mitigating endless taxonomy iteration.
Taxonomy governance should be part of a greater data governance framework including business and technical stakeholders from across the business. Establishing a data governance framework lends credibility to data handling across the enterprise and provides enforceable common ways of working. When signed-off and adopted by participating members, the principles can also be cited when taxonomy work begins to slow in endless review cycles and disagreements. Not only are taxonomy best practices a lever for moving taxonomy development forward, but data governance can provide clout for resolving stalemates.
The Right People
A common problem leading to multiple taxonomy reviews and revisions is not including the right people in the initial discussions. Not including the right people can be symptomatic of narrowly defined projects which only serve one business unit or a specific use case. Identifying the right subject matter experts and technical resources is essential to developing taxonomies that can scale across the enterprise and its many use cases. As part of the system, process, and content audit, be sure to identify anyone who is currently using metadata schemes which may include or be replaced by taxonomy values or processes which are automatically driven by current metadata values. Conducting interviews and taxonomy workshops to reach as many potential stakeholders as possible will help to mitigate the number of reviews a taxonomy will need.
A natural outcome of establishing data governance is the identification and inclusion of the right business and technical stakeholders. Because these people are identified as part of data governance, they can be included as needed in taxonomy development conversations so potential needs–like legal or regulatory review for taxonomy concept forms or system impacts–can be immediately addressed rather than coming up later in the development process and effectively derailing the previous work and decisions.
Document Decisions
Another key task for mitigating taxonomy iterations and development deadlock is documenting decisions. In many taxonomy management systems, decisions can be documented within the taxonomy itself in the standard skos:editorialNote field. Decisions can also be documented in the documentation preference of the organization, such as a Confluence wiki page. Depending on the ticketing system, decisions made about the taxonomy with the business can also be noted in the ticket request itself, for example in a Jira ticket. A taxonomist may use one or all of these locations to note what decision was made, when, and by whom. Even if business stakeholders change or significant time passes, the decision indicating a concept form, why a property or relationship was added, or why a concept was changed or deprecated can all be viewed by the current parties involved.
While taxonomies are living, breathing, changing, and evolving data structures, these changes need to be logged to understand why decisions were made and what impacts, if any, those decisions have on taxonomy development and delivery.
Taxonomy development and iteration can grow and scale with business needs, but can also be subject to slowdowns and bottlenecks if there is no recourse to resolution. Hopefully some of the techniques above can help mitigate taxonomy stalemates and gain trust in taxonomies and their ongoing development cycle.
Themes and Trends from Taxonomy Boot Camp London
“And history was the reason why she would never go to London. She saw it as dominated by the Bloody Tower, Fleet Street full of demon barbers, as well as dangerous escalators everywhere.” – Anthony Burgess, Inside Mr. Enderby
After a six year hiatus initiated by the Great Plague of 2020 and continued with a lost conference venue, Taxonomy Boot Camp London returned in 2026 at the America Square Conference Center. The event was co-located with the KMWorld Europe conference, allowing attendees to come together for keynote sessions while attending one of two tracks for each conference. Just blocks away from the Tower of London and literally encompassing part of the ancient walls of the City of Londinium, the steadfast and ancient hosted audience to the rapidly changing world of knowledge organization systems and artificial intelligence.
As with past conferences, I’m going to sum up some of the key themes and trends of Taxonomy Boot Camp as I heard them.
Working with AI
A prevalent theme across all sessions was working with AI rather than against it. While there is common concern that AI will replace jobs and remove the human from the work equation, most sessions focused on using AI as a tool to accomplish tasks that are repetitive, time-consuming, or inconsistent. In particular, using AI to identify and extract entities for taxonomy building or inclusion, summarizing large quantities of text, or automatically classifying content using taxonomy values.
Another key focus was on the probabilistic notion of machine learning models:
At a high level, probabilistic AI models uncertainty and provides outcomes based on likelihoods. This means that it doesn’t always offer one definitive answer but instead provides a range of possibilities with associated probabilities. Deterministic AI, on the other hand, is rule-based, designed to yield specific, predictable outcomes without room for variability once given a particular input. (Decision Point Advisors)
Machine learning models may generate different answers to the same question, often termed a “hallucination”. Grounding machine learning models in knowledge bases, including deterministic models like graphs in the form of taxonomies and ontologies, can create a neuro-symbolic AI approach providing more consistent answers.
Content and Training
Working with AI also means curating the training data made available to machine learning models. Publicly available large language models (LLMs) are trained on easily accessible large data sets…specifically, content available on the Internet. As we well know, content quality on the Internet is as varied as the people who create it and make it available. While LLMs then get the benefit of a variety of input, they also suffer from the biases inherent in that input. Using synthetic training data or retrieval-augmented generation (RAG) to supplement the pre-existing LLM training data can improve results. In particular, using organization-specific knowledge bases of training data can help provide more specific responses applicable to your domain with fewer erroneous answers.
Deciding what training data to use and how taxonomy and ontology structures become part of that training data is partially in the purview of taxonomists, so becoming familiar with which LLMs are being used and for which use cases will be important parts of a taxonomist’s changing role.
Language Consistency
While this is nothing new, many sessions focused on keeping the “controlled” in controlled vocabularies. Since nearly every session linked back to AI in one way or another, even the context within which we consider the basic tenant of control in a controlled vocabulary was emphasized as continually pertinent. With differences in language across one or more semantic models, machine learning outcomes are put at risk. As more areas of application for machine learning are being found, we are also venturing into areas involving more risk, like mental health or medical advice, legal enforcement, and financial decisions. Language consistency used in semantic models and as applied as metadata for training content is now more important than ever.
Among the use cases pertinent to this consistency is tagging documents at more granular levels, including inline tagging and tagging content chunks. Again, this is nothing new and has been a practice of DITA for 20 years. However, being able to consistently and accurately create training data to balance probabilistic large language models with deterministic knowledge can counter machine learning hallucinations and create more trustworthy AI agents.
“Bond”ing
And, although not a taxonomy or knowledge management theme, I did notice another commonality across at least two presentations: James Bond as an example. Perhaps it was the London venue that caused presenters to use our favorite secret agent as an example, but there he was, connected semantically to movies, sports cars, and identification numbers. I myself created a simple Bondtology for illustration purposes in past workshops and webinars. Interesting that a profession like spycraft met at the intersection of establishing deterministic truth through semantic models to avoid being deceived by artificial intelligence.
Taxonomies and the Fall of the House of Escher
“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.
Smoke and Mirrors
“But it’s always been a smoke and mirrors game / Anyone would do the same.” – Gotye, Smoke and Mirrors
It’s pretty common for organizations to have many software systems and platforms. Some are home grown, some are commercial; some have small scopes while others are enterprise grade; some are legacy while others are newly rolled out; some are seamlessly integrated while some (um, many) are standalone and siloed. What many of these systems have in common is that they are dedicated to one or more functions. They may be for digital asset management (DAM), content management (CMS), product information management (PIM), customer relationship management (CRM), and so on. Something that few enterprise systems do well is taxonomy management. And, to be fair, why should a standalone system dedicated to a particular purpose also be excellent at taxonomy (and ontology) management? There are dedicated systems for this function as well.
Typically, taxonomy management systems (TMS) are positioned as centralized repositories for controlled values which can be integrated with multiple systems in a hub and spoke model. A centralized taxonomy architecture ensures single concept values with a unique identifier can be used across multiple systems for many use cases. A centralized architecture makes sense, but there are many challenges arising from consuming downstream systems’ inabilities to handle the rich semantic models published from a TMS. Consuming systems may not be able to ingest properties, relationships, or even hierarchies.
What are some ways we can address these integration issues while maintaining an architecture in which a TMS is a centralized source of truth for metadata values?
Smoke and Mirrors
When the first iPhone was released, it shifted paradigms. The original iPhone wasn’t the first device to include touch screens, but its form and user experience was unique in many ways. Apple is touted for their designs, and it was the combination of form and function that garnered such immediate success. We didn’t learn the iPhone, the iPhone taught us. We learned to scroll, swipe, and tap so these basic functions became ubiquitous across many devices and manufacturers. A good user experience will do that: teach us how to navigate through an application, how the functionality works, where we should expect to find a “yes/no” or “next” button, and the overall design principles. I see this as domain teaching and reinforcement.
The same is true in the world of semantics. As semantic practitioners, we must educate users and meet them at the level of their knowledge need. Some business users will only need to know the basics of taxonomy principles when a taxonomy redesign is in progress or they are onboarded as taxonomy consumers. Other business partners will want to become more involved in the process and go beyond concepts into modeling the semantics of their domain.
Modeling conceptual domains is what semantics is built for, reflecting the ways of thinking in the organization, including business processes and relationships between concepts and things. Semantic models are mirrors of organizational thinking. Consuming systems may be mirrors of these mirrors, even when they are not designed to be semantic modeling platforms themselves.
The most basic smoke and mirrors game is aligning concept label values across systems. While the values may be mirrored, it is more smoke than anything else, concealing the incredible amount of overhead in agreeing on the label values, maintaining the governance process to ensure these labels stay aligned, and workaround maintenance required by the nuanced differences between consuming systems. In these scenarios, any necessary change in any of the systems (including the taxonomy as an aligned source of truth) can be precarious as downstream values may be driving workflow processes or are hard-coded, making them extremely difficult to change.
Consuming systems supporting hierarchy, definitions, and synonyms can mirror hierarchical structures and at least some of the properties adding semantic context to concepts. Consuming systems only supporting flat lists may have the ability to create dependent fields. Although not a true hierarchy, selecting a value from one field that constrains the values in another field mirrors hierarchical structures. Again, mostly smoke and mirrors concealing the amount of semantic design it takes to understand which parent values may drive dependent fields and how the child concepts are displayed. A more advanced step toward alignment is ensuring that all of the values share a common ID, even if this ID is manually entered for each mirrored concept so they are the same across systems. Not ideal, but having a unique identifier for each concept can bring these concepts closer together even if they are pulled directly from a source of truth taxonomy management system.
More Mirrors, Less Smoke
The best way to take advantage of semantic models is to pull taxonomy concepts and their associated properties—including fields like description, scope note, and the URI or GUID—into consuming systems so there are taxonomy terms for metadata tagging and their associated attributes for context and additional information. Tagging interfaces might be dropdown lists of 10-15 values, hierarchical browsing, or typeahead fields displaying taxonomy concepts as the user enters characters. All of these methods of applying taxonomy concepts reinforce the terminology used in the organization. Dependent fields and hierarchies reinforce hierarchical relationships between concepts and reveal how ideas are organized.
Users less frequently see full ontologies including concepts and the relationships between them. However, revealing these structures in browsable visualizations can be useful to help users understand concepts and the relationships between them. Again, these semantic structures mirror the activities of the business. If users can see interrelated concepts, and preferably in the context of content tagged with those concepts, it reinforces the mission and activities of the business. Additionally, showing graph visualizations can help shift thinking from simple hierarchical structures to more semantically rich graph structures. When business users understand the current domain thinking, they can also begin to understand how these semantic structures can be applied to business use cases to solve common organizational problems. In addition to active education by taxonomists, user interfaces and mirrored domain modeling in systems can help users understand semantic modeling and what it can do for the business. Revealing semantic models can be reinforcing, but it’s probably less common and useful than more practical mirrorings in systems that don’t have particularly strong semantic foundations to begin with.
Conceptual domain mirroring takes creativity, using the functionality of the TMS, APIs, and consuming systems to create an ontological and graphical domain representation even in systems that are foundationally relational and hierarchical. Taxonomists, working hand in hand with information architects, can find opportunities to express the complexities of semantic models in existing UIs and through creatively creating new ideas meeting the use cases of the business. Mirroring domains creates organizational alignment and reinforces domain thinking without conscious effort by the users. Just as well-designed hardware and software teaches us new domains, so can we as semantic practitioners find ways to passively educate our users about domain thinking and semantics in the organization.
The AI-Taxonomy Disconnect
“Me, I disconnect from you.” – Gary Numan, Me! I Disconnect from You
I have seen a significant decline in the number of taxonomist positions available. Wondering if I was in a myopic bubble based on my location or choice of job boards, I’ve been asking colleagues if they see the same thing. The general consensus is, yes, there are fewer taxonomist jobs available even as the importance of foundational data structures are becoming more important with AI tools. I have seen an increase, or at least a steady availability of, ontologist jobs, many requiring more technical expertise (the ability to create Python data ingestion pipelines and retrieval augmented generation (RAG) systems) than I have seen in the past. Again, this may be a matter of where I live or where I am seeking jobs, but it seems jobs in the taxonomy and ontology field are becoming more technical and less focused on the business operations side of working with stakeholders to provide analysis and guidance on semantic frameworks.
I suspect this shift is driven by a wider adoption of AI tools and a contraction in the job market. Employers seem to be seeking a single resource to do both the business and technical sides of implementing semantic structures and the foundational components for building out applications. I wonder if another factor is also the belief that large language models (LLMs) are a replacement for semantic models. If true, there are several reasons I can see that may be driving these beliefs.
Speed to Business
As I have touched upon before in my blog (Friction and Complexity and The Taxonomy Tortoise and the ML Hare), the manual, slower, but deliberate curation of controlled vocabularies can be seen as a roadblock to business speed and agility. There are several valid points here.
One area of pushback I see frequently in organizations is the response time from initially requesting a new concept, taxonomy branch, or vocabulary until it is available in production. The ownership of the concepts and data is, to some degree, taken out of the hands of the business users and put under the control of taxonomists who incorporate these concepts into centralized semantic models (taxonomies, thesauri, ontologies). Even with governance models including service level agreements stating turnaround times and taxonomy availability, not every group in the organization is going to see this centralized service as a benefit. Rather than wait for enterprise-level support, stakeholders may develop workarounds in services and tools to support their own use cases. As we know, this decentralizing of schemas and tools creates a fragmented landscape of differing terminology, functional support in what tools have available to manage taxonomies, and processes in the way data and content is handled and tagged with metadata.
Similarly, enterprise taxonomists serving many areas of the organization may seem to be too domain agnostic to serve the variety of use cases served by controlled vocabularies. While taxonomists do not need to be a domain expert in the areas covered by semantic models, the perception may be that their time spent ramping up in a domain would be better served having the subject matter experts in those domains build their own models. There is some validity here if the domains are truly standalone and operate to serve only those domain use cases. However, tying together various domain areas to form enterprise-wide knowledge graphs seems to be the direction most organizations want to go. If that’s the case, then a centralized taxonomy team as a service to the entire enterprise makes a lot of sense.
Given these counterpoints to slowly developing semantic models, why not, one may ask, simply ask machine learning models to provide the schemes we need to organize and optimize information?
Words Are Words Are Worlds
Are LLMs seen as a replacement, or at least a viable alternative, to taxonomies (using the term as a broad umbrella for all controlled vocabularies?
A large language model (LLM) is a language model trained with self-supervised machine learning on a vast amount of text, designed for natural language processing tasks, especially language generation. The largest and most capable LLMs are generative pre-trained transformers (GPTs) and provide the core capabilities of modern chatbots. LLMs can be fine-tuned for specific tasks or guided by prompt engineering. These models acquire predictive power regarding syntax, semantics, and ontologiesinherent in human language corpora, but they also inherit inaccuracies and biases present in the data they are trained on (Wikipedia).
Certainly building your own language model reflecting all of the ways that natural language queries could be asked is non-starter when there are clearly highly performing, public LLMs available at our fingertips. The chatbots ChatGPT, Google Gemini, and Microsoft Copilot are some of the more familiar tools based on foundational LLMs. One of the primary, and arguably most successful, use cases for these tools is language generation. When prompted, a chatbot can generate text, format this text based on instructions or examples, and produce a slick product which, short of a quick review to ensure the content checks out, is ready to go. These LLMs are based on a “vast amount of text”; in short, a lot more text than you will be able to provide to train a whole model.
What LLMs are missing, however, is your context. There are many, fairly easy, methods for providing them context. You can allow them access to your documents, at work or at home, so the chatbot can “see” the content of your documents, the structures, and even the writing style. That is very much your context, allowing the chatbot to compose in a way that reflects your home or work artifacts and generate new text combining the existing LLM with your specific context. Using additional context moves an LLM from generic to specific, from a wider world of words to your world of words.
At enterprise scale, the same method applies. If your organization is large, has a lot of public exposure and presence, and has a history of public interaction on the Internet and in social media, LLMs are going to know a lot about you even without additional context. I think, however, for the same reason that the market for reusable, one-size-fits-all taxonomies has never taken off is that every organization—whether true or not—is unique and special. Outside of certain industries like healthcare, life sciences, pharmaceuticals, and finance which have well-defined, and often extremely complex, ontologies they can adopt, other industries or functions within a company do not. In my experience, marketing is a great example. Despite the common needs, I have never seen a marketing department adopt any public standard. They build from scratch even when a majority of the taxonomies are commonly available terms.
In these cases, building taxonomies and ontologies to add context specific to your organization provides LLMs with both words and structures modeling the world of your domain. In fact, it is becoming more common that the development of these taxonomies is being done with human-chatbot interaction. A taxonomist can provide glossaries, metadata schemas output in spreadsheets, and documents to provide chatbots with the raw materials to extract entities, cluster topics, compare values across documents, and other processes that once required text analytics tools and, sometimes, human intervention in the form of rule writing. The speed to taxonomy and ontology development is increasing. Like other iterative feedback processes, the taxonomist and LLM work together to create domain schemas in the form of taxonomies and ontologies that provide additional guidance to future “manual” and automated processes with LLMs in the mix.
Pure speculation on my part, but is the niche and sometimes still esoteric and obscure field of taxonomy and ontology design being replaced, for better or for worse, with LLM use? Or, more specifically, is it being viewed as a replacement for taxonomy and ontology building and the experts who do it? As I stated above, I have seen a shift from the business of taxonomies to the technology of ontologies.
I Disconnect from You
In my opinion, the roles of a taxonomist and of a technically skilled ontologist are still separate. While many people in the industry have the skills to do the work of both, the paths to the two roles have been different. Many taxonomists have library science degrees. They likely have technical skills, but are more focused on the information science aspect of taxonomy and ontology development, interfacing directly with the business and providing other services, such as research, business analysis, and support for use cases relying on semantic models. Ontologists are typically computer scientists who can code and develop the technical infrastructure for ontologies. Finding resources who can, or who like, to do both has not been common. This may be changing. Certainly the roles are asking for both, with, in my view, a leaning toward the technical.
Again, speculatively, is there a shift toward more technical resources in support of rising AI use in organizations? Is there a move to cut out the intermediary roles of taxonomists to let the business owners and technical implementers of taxonomies and ontologies interface more directly? If so, what do organizations lose in the process?
The Connect
If I were reading this blog, I would think the author was trying to sell you the value of taxonomists with more of the “soft” skills of research, business stakeholder interaction, and translation of business requirements into taxonomies and to the more technical resources who support their implementation and move to actionable production. After catching up on a few seasons of Landman and hearing in my head at some point in every episode, “Brought to you by [insert name of large oil company]”, maybe I’m a little sensitive to reading between the lines. You don’t have to. I am selling you on the value of taxonomists for all of the reasons I’ve listed above. If there is indeed a shift from the business skills of taxonomists to the technical skills of an ontologist instead of having the excellent skills of both, then your organization is missing out on a valuable resource who can work alongside AI technologies to bring the business requirements and practical domain building skills to bear.
In summary, believe there are two necessary components to bridge the seeming disconnect between AI and the foundational data quality governance needed to make AI operational:
- A taxonomist who can
- build taxonomies and ontologies to create domain-specific semantic models representing the business,
- provide business analysis and requirements for technical implementation, and
- be the human-in-the-loop working with AI tools to continue building out, expanding, and governing semantic models, and
- Technical engineers who can
- operationalize ontologies by building data pipelines to AI tools, and
- focus on the engineering aspects of sharing out and productionizing ontologies for use across the enterprise.
An enterprise with both of these roles isn’t creating unnecessary resource overhead or additional layers effectively slowing the path from automation to implementation; rather, the two roles work in harmony to clarify requirements and optimize the use of AI in a variety of applications meeting business use cases. Taxonomists and ontologists are bridges between the business and the technical implementation enabling business needs.
The Art of Taxonomy Workarounds
“With the greatest of ease / I stay on track like the greatest of skis.” – Stress Eater, Czarface, Kool Keith, Rocket Science
In all my years working in taxonomy, there have been few times I have walked into an environment that already had a robust taxonomy program supported by a dedicated, centralized taxonomy management system (TMS). Far more common was that there was no taxonomy program or tooling established yet. There are many ways taxonomy programs begin at an organization, but in most cases, there is a period in which taxonomy work must be done in tools insufficient for true enterprise taxonomy management.
Not moving forward with taxonomy development or waiting for a proven use case or budget necessitating a dedicated system are rarely options when laying down the foundations for an enterprise taxonomy program. What do taxonomists do in the meantime? How do they stay on track with taxonomy development while waiting for the right tools to support scalable taxonomy? There are always taxonomy modeling or tooling workarounds (I suppose someone with better clickthrough titling would call these “taxonomy hacks”) to get taxonomy programs started while the case is being made and the budget is allocated for a robust, centralized TMS.
Spreadsheets
I have never met a taxonomist who didn’t start taxonomy development in spreadsheets. The random glossaries and lists you might find in unstructured PDF or text documents during a vocabulary audit are great taxonomy starting points, but truly actionable and useful current or potential taxonomy values live in spreadsheets, either as a reference file or as a metadata schema output from an active system.
Some of these files output from existing systems might have hierarchy, but I would expect that more often than not, the spreadsheet is a set of columns with flat lists. There may be dependent metadata fields in which a selection from one list drives the values appearing in the next list, but all of the lists are flat. From these outputs, taxonomists taxonomize, adding hierarchy, synonyms, definitions, and other columns into a spreadsheet format ingestible by a future state TMS.
Not every organization has the budget or can be convinced to find the budget, so taxonomies in spreadsheets may be the beginning and end of your taxonomy management tooling. It is possible to do a “pencil and paper” taxonomy management program in which a highly governed, single source of truth spreadsheet is fed, in whole or in part, to consuming systems. It may even be possible to assign the taxonomy concepts unique IDs, synonyms, definitions, and other property fields which can be ingested into consuming systems so there is more than concept labels to work from for tagging and analytics.
I don’t love management by spreadsheet as an enterprise taxonomy program, but it’s certainly a step in the right direction and a level of maturity above no centralized taxonomy management at all. The benefit of such an approach is that there is so much painful governance and process management overhead that eventually there are one of two outcomes: no more taxonomy management or the push for better tooling. Spreadsheet management is the roughest hewed of the workarounds.
Not Taxonomy Tools
The next level of enterprise taxonomy management with potentially few workaround issues are systems that “do taxonomy management” that certainly do not do taxonomy management by most taxonomists’ standards. These include tools like digital asset management (DAM) and content management systems (CMS). These tools are really term management tools at best since they don’t include any of the functionality to move from a term to a fully fledged concept.
Perhaps the most notorious of these smooth criminals is the SharePoint Term Store, which is great for all things SharePoint in SharePoint and in SharePoint only. But, all of my snide comments aside, works well enough if most of your work is in SharePoint. The Term Store does include hierarchy (but not polyhierarchy), synonyms, definitions, and generates unique IDs for each term. The management is relatively easy and there are manageable limits to hierarchy depth and total term count.
I was recently at a DAM conference and asked a vendor about their taxonomy management functionality. I suggested it would be a temporary stepping stone until the organization I was working for could move to a dedicated enterprise taxonomy management system. He asked with incredulity, “But why would you want to manage taxonomies anywhere but in the DAM?!” Now that’s dedication to your product! In a world in which all digital assets are created, managed, and reused in a single system without needing any overlapping metadata application to any other content for any other purpose, I guess you wouldn’t need to manage taxonomies outside the DAM. Somewhere in this alternative marketing-only dimension, the taxonomies never see anything outside the DAM.
DAMs do manage taxonomies to some extent because metadata is absolutely essential for unstructured content with little or no text to search against. The only way to properly search for and reuse digital assets is to have associated textual metadata. The limitations in these systems are typically a series of managed flat lists with the ability to include dependencies between selected values, potentially reducing the amount of time it takes to apply metadata and the number of choices someone has to wade through to get to the right values. Some DAMs do include some shallow hierarchy in the taxonomy management and hierarchy can further be built out by using lists in a predetermined hierarchical folder structure. You can get quite a bit out of this taxonomy and folder harmony, including inherited taxonomy values. These structures tend to be inflexible and require heavy lifts to change after they are already in use. Most DAMs generate some kind of unique ID for each term. You may even have fields for synonyms and definitions, but there’s not much you can do with these properties.
I’m being pretty hard on the taxonomy capabilities of these systems, but they are a step up from managing taxonomies by spreadsheets. What they sorely lack to be an enterprise TMS, however, is the ability to tag with the same metadata values outside the system, requiring aligning taxonomies across systems by label only. Matching by label is severely limiting and requires a phenomenal amount of overhead in business alignment and the actual execution of any changes to taxonomy values, which may need to be updated across multiple systems within a reasonably short timeframe. All this not accounting for values which should not or can not be changed because they drive system workflows or create orphaned content when the term label changes.
Another fundamental problem that non-taxonomists working in a DAM or CMS can overlook is that, even with the best governance and alignment between systems, the taxonomies are always separated by system location and proprietary technology. Any alignment of taxonomies is surface only, mapped by label or ID matching. Taxonomy management across systems in this way is tenuous and unsupported by common technology and standards architectures. Thus, while working in systems that are production ready, the taxonomy alignment across systems is only slightly better (if better) than managing taxonomies from a single source of truth spreadsheet.
The Workarounds
Now that I’ve outlined the tooling supporting workarounds when an organization does not have a TMS, what can taxonomists do to make sure these workarounds are as painless as possible to move away from and toward a proper centralized solution?
Design for the future. Despite taxonomy tooling limitations, there are still several fundamental taxonomy construction best practices taxonomists can employ to help future-proof the taxonomies and ready them for import into a TMS. While you never know what strategic shifts an organization may make, including changing branding, mergers and acquisitions, and responses to social and technological change, there are core taxonomies which won’t change much from organization to organization. Designing around repeatable, core taxonomy domains and creating faceted taxonomies like Content Types, Geography, Products, and Topics can reduce large modeling changes within one system or when migrating from one system to another. Setting up separate, mutually exclusive and collectively exhaustive (MECE) faceted taxonomies allows for greater flexibility to add or subtract vocabularies as needed, including the ability to take in publically available vocabularies as part of the mix.
Even significant limitations like lack of hierarchical support does not need to prevent the development of taxonomies prior to using a TMS. Admittedly unwieldy, creating separate faceted taxonomies as flat lists in systems that don’t support hierarchy can get taxonomies into production. Once a TMS is purchased and the existing flat taxonomies are being imported, hierarchies can be created in spreadsheets in exported files, designated as parents and children in other file types before import, or manually created in the tool itself after import. If there are no label changes or there are unique IDs for each concept, hierarchies can be created in the new TMS while still mapping to the original concepts used to maintain tagging continuity.
Unique IDs. Unique Uniform Resource Identifiers (URIs) are a core concept of taxonomy management systems based on RDF, SKOS, and OWL. URIs ensure that any concept label and its associated properties and relationships are unique, even in cases where labels match but the contextual meanings don’t (though, of course, this should be avoided). No matter what happens to a concept label, the URI remains the same across systems, allowing system users to do things like use an alternative label as the preferred label or consume different concept properties. At the end of the concept lifecycle, when users are looking to aggregate data from multiple systems for business intelligence and analytics, knowing a single concept URI exists without having to map several labels to understand the data is a huge burden off analysts.
While many systems generate some kind of ID, there can be limitations. For example, some systems generate an ID based on a namespace combined with the label name. In such a case, the system may not allow for taxonomy labels to be the same because the ID will then be the same. However, these restrictions may not exist and the system will generate the same ID for two labels which are the same but have different hierarchical contexts. Scenarios like these are exactly the reason unique URIs are a differentiator in taxonomy management. The way IDs are generated can have an impact on the way you design taxonomies in platforms that weren’t meant to act as centralized TMS.
Whatever the case, creating unique IDs with the tooling you have at hand will help to provide history and concept continuity when moving to a TMS. While not common, label names can change. An acronym can be switched out for the full form or an organization name may change (Twitter to X, for example). In these cases, matching label to label across systems won’t maintain any historical context. If the concept has a unique ID which does not change, then these can follow the concept wherever it goes. Finding the equivalent in your systems or creating them manually in spreadsheets allows for mapping back to URIs by property or label when moving to a TMS.
Clever properties. If you have acknowledged the limitations of the system in which you are designing taxonomies for the future, then you use several modeling practices to make the migration into a TMS easier. Rather than supporting a mapping table, you can create a property to house the taxonomy concept ID from the old system. Upon import, every concept will be assigned a new URI in a TMS. URIs are typically the combination of a designated namespace (http://www.myorganization.com/enterprisetaxonomy, for example) with the name of the concept or an alphanumeric ID appended at the end (http://www.myorganization.com/enterprisetaxonomy/myConcept). Namespaces and ID generation patterns can typically be set in the TMS to generate unique IDs based on an existing company policy or can be newly established. Maintaining the old concept ID from legacy systems provides historical context and can prevent significant content retagging by mapping the newly generated concept in the TMS to the labels and IDs used previously.
I’m making this sound easy, but there are always going to be some challenges moving from legacy tooling to a new TMS. That said, the transition can be made easier and maintain concept continuity by planning ahead and building mechanisms into the taxonomy modeling itself to tie legacy taxonomies and tools to the taxonomies in a new TMS. An organization may never get out of the workaround phase of taxonomy management, but using taxonomy modeling and tooling best practices will make governance a lot easier.
KMWorld 2025 Themes and Trends
“But I’m a creep / I’m a weirdo / What the hell am I doin’ here? / I don’t belong here.” – Radiohead, Creep
I attended the KMWorld Conference and two of the four co-located sub-conferences, Taxonomy Boot Camp and Enterprise AI World, in Washington, D.C. last week. It was the 20th Anniversary of Taxonomy Boot Camp, and although I raised my hand when asked if I had attended 10 or more, I had never actually bothered to count how many years I’ve been to the conference. It turns out, I have attended KMWorld and the co-located conferences for 13 years out of the last 18, with my first being the 2008 Enterprise Search Summit West when it was still hosted on the West Coast in San Jose, California. Over this span of time, I’ve seen trends rise and fall, fears realized and alleviated, promises promised and promises kept.
Every year there seems to be at least one theme I can carry away from the conference, and for several years, I’ve written about the themes and trends from the conference as I see them. Some of these blogs are hosted on the Synaptica website and on my personal blog at Information Panopticon. I will go into some of those themes and trends as I did last month in my recap of the Henry Stewart Semantic Data Conference and HS DAM.
After many discussions at the event with colleagues in the industry, I can confidently state there was one overarching theme: things are weird.
Things Are Weird
What’s weird in 2025? Seemingly, everything. While the wider world may be as weird as it’s ever been, the state of knowledge management, taxonomy, and related fields covered by the conference have been supremely weirded and mostly by AI. There has been a rapid shift from feelings of dread that AI is coming for all of our jobs to an embracing acceptance that those who use AI as a work tool will maintain their place, or even excel, in the industry.
Despite this acceptance, the industry is still weird. In the world of taxonomy, we all understand and believe that AI and its need for clean, curated, semantic data will necessitate good taxonomists and taxonomy systems. However, while the bottom hasn’t completely fallen out of the market, there seem to be fewer jobs, more unemployed taxonomists, and lower salary and contract rates. Maybe it’s the generalized uncertainty in the tech sector driving the slump, but many people I spoke with at the conference think that it’s a misunderstanding of AI foundational needs that’s causing companies to lay off taxonomists and invest in AI more heavily.
What else is weird is how excited everyone is about AI but how few companies have managed to successfully bake AI practices into their processes. We’ve seen the incredibly successful use of AI in text summarization and generation, particularly when it comes to meeting minutes and the identification of who said what and what action items were decided upon. Agentic AI has had some success, and taxonomists seem to be working at skilling up in prompt engineering using already existing taxonomies and ontologies and generating new taxonomy options from generative AI prompts.
What was very weird for me is when you hear people in taxonomy talking about the auto-generation of taxonomies who (including myself) for years said that the results of autogenerated taxonomies were mediocre at best, you know there’s been a seismic shift in the industry.
AI in Everything, Everywhere, all at Once
Like every other conference I’ve attended this year, the focus is on AI. Something that was different this year, in my opinion, was the amount of more practical applications and use cases that were presented. While AI still hasn’t found its stride when it comes to maximizing ROI in a variety of use cases, there were very informative sessions on what skills knowledge management and taxonomy specialists need to master in order to work in an AI world. I have seen this reflected in the job market. There are still taxonomy and ontology roles being posted, but there are many more requiring technical skills like Python as part of the role. In essence, companies seem to be looking for people with both the business skills to build and manage semantic models as well as the technical skills to implement them in AI applications. While I know these people exist, I don’t know how common they are. People at the conference felt that there will always be a need for taxonomists who do not have deep technical skills, but an acknowledgement that getting skilled up in prompt engineering is a differentiator.
Several presentations in both the KMWorld and Taxonomy Boot Camp conferences focused on AI readiness. What does an organization need to appropriately identify AI use cases, guardrail the data within the organization so only what is appropriate is available to AI tools, and determine how humans fit into the process? Since generative AI can extract and generate metadata candidate concepts, it’s important to understand the results to interpret their trustworthiness and value. Many of these concepts are net new and should be added to taxonomies as concepts, properties, or relationships. Other values are net new but are ephemeral or trending and can be used in search, for example, but aren’t yet established enough to be codified in semantic models. Other concepts will already be in the taxonomy and can be discarded unless they are used to inform which content includes taxonomy values and should be tagged appropriately. Finally, some generated concepts are garbage or nonsense and should be used to inform and improve the machine learning model. All of these questions need to be answered and processes decided upon and put into practice.
Another common theme was the use of taxonomies and ontologies to inform and refine prompts and to support Retrieval Augmented Generation (RAG) with or without labeled content as part of a knowledge graph. Taxonomies and ontologies supply the domain specificity required to augment large language models (LLMs) to inform them of the specifics of the organizational perception. In short, using internal semantic models is a shortcut to providing the book of knowledge about the organization. What was once a topic in only a few presentations seemed to be much more prevalent this year.
As I mentioned earlier, organizations are now in the phase between conducting proof of concepts on AI in the organization and the need to productionize and provide ROI on AI in organizational workflows and processes. If the AI bubble is stretching, the continued low adoption and ability to prove ROI for organizations will cause the bubble to burst. The AI industry will only continue to grow and expand if there are tangible benefits increasing the bottom line of organizations who have adopted the practices and scaled them into production.
Taxonomy, Data Governance…and Where Is the Data?
At least two presentations focused on the intersection of semantics and data governance. These both stood out to me because I have experienced the intersection of semantic models and highly governed data in data lakes myself as there are frequent conversations about who owns which data and what is the ultimate source of truth. How do internally developed taxonomies and ontologies fit into the overall data governance model? Who owns which values in which systems? How are the practices similar and different?
In his keynote, Malcolm Hawker simplified two key aspects in the different disciplines. In data governance, one of the main concerns is accuracy and precision for measurement. In taxonomy, the focus is on meaning, or semantics. Bridging the two disciplines is the bringing together of measurement and meaning. AI is a motivating factor in reconciling the two disciplines due to the need for clean, structured data and its use in tagging unstructured content. Although the approaches to relational database focused data management and graph database semantic data are different, they are complimentary functions ensuring the best data quality in an organization.
Beyond who creates and owns the data and in which system it lives, organizations may be trending towards moving back to “walled gardens” of data to use in AI. The difference between public tools like ChatGPT and using LLMs within an organization puts the emphasis on what data is shared with the model and which users can see it. Since many AI tools use publicly available information on the Internet, organizations may protect their data and bring more of it in house so it is not available to such tools externally. Similarly, the concept of having a sovereign cloud, in which data is housed in the cloud but designed to meet regional data requirements and regulations, is probably gaining traction. Where there have been so many efforts to make data and content freely available, there is also recognition of which data should be available to machine learning models both to produce reasonable outcomes and to protect organizations and individuals. As states, provinces, countries, and regions pass additional laws about data, privacy, and AI, parsing out which data is subject to which regulations is becoming more difficult. Separating data in sovereign cloud environments may be a key to addressing this challenge.
In Summary
Things are weird, but the foundational value of semantics has not disappeared. The focus has changed and the toolsets we use to create and productionize semantic models have expanded, but the need for clean, accurate, source of truth metadata has only grown in importance.
Semantic Data 2025 Themes and Trends
“Trust in me, just in me / Shut your eyes and trust in me” – The Jungle Book
I attended the Henry Steward Semantic Data Conference co-located with HS DAM in New York City a few weeks ago. As I’ve done with KMWorld in the past, I’m going to summarize some themes and trends I took away from both conferences, with an emphasis on Semantic Data.
Inevitable AI
The most common theme of both conferences, unsurprisingly, was artificial intelligence (AI) in all of its forms, applications, and impact. Broadly speaking, the key takeaway across all of the presentations and discussions was: this is happening. Whether it’s baked into digital asset management (DAM) systems (hint: it is), used wildly thrown at use cases until something sticks, or carefully governed with strict governance, guardrails to protect the organization, its people, and the people they serve, and measured to understand the effectiveness of different large language models (LLMs), AI is happening. So what do we, as digital asset and semantic data professionals, do about it? What is our role in the use of AI in the organization and in the public sphere? What are our responsibilities?
From the Semantic Data Conference, several themes emerged:
- Organizations are going to experiment with generative AI models to develop workable pipelines with humans in the loop;
- Context is key, and organizations can develop domain-specific and constrained semantic models to be used in conjunction with external LLMs;
- It’s incumbent upon all of us to develop valid, organizationally-specific and curated training data sets to provide machine learning models the context to output reasonable results.
Themes from the Digital Asset Management Conference included:
- AI can speed up the generation of assets and the automated application of metadata to those assets;
- Access to clean, curated metadata is critical, both from taxonomies and sources like data lakes;
- Metadata as a source of truth for embedded AI can lead to better analytics;
- Asset provenance is essential for usage and rights management, especially when AI is involved.
Metadata Is Critical
That’s it. That’s the story. Metadata is critical. It has been, and it will continue to be. But, maybe, organizations are more aware of the importance of metadata because of the lightning fast rise of AI. Metadata is critically important as applied to digital assets, and semantic metadata powers better asset connections, discovery, personalization, and analytics.
Core to the importance of metadata is the importance of trust. Metadata quality must be trusted. The data and content to which metadata is applied must be trusted. Quality, trusted data leads to quality, trusted content and training sets which can feed into AI pipelines. Similarly, legal and reputational risks can be mitigated by ensuring the quality of information and data, especially as applied as compliance and usage rights.
Since semantic models are a source of truth for quality metadata, developing taxonomies and ontologies over time can create more complexity as needed to support a variety of use cases. Complexity sounds like a negative, but the world is complex, and semantic models are meant to represent organizational domains, which are by necessity complex. Complex semantic models support a variety of use cases, even if they do take more conscientious planning, development, and governance. Within these complex models are fit-for-purpose structures addressing use cases.
As with AI processes, developing, managing, and governing metadata in all its forms involves humans in the loop. Even as the identification, extraction, and application of metadata improves with AI, humans need to be involved in the process to add, remove, and quality check automatically applied metadata. As pipeline processes improve, reaching a specified threshold of metadata accuracy may reduce the need for human intervention and review.
Context and Trust
If I had to boil the conference down to two keywords–or, maybe, if I could only apply two metadata tags to the conference–they would be context and trust. Data and content requires context and semantic models are one way to provide this context whether for use in machine learning pipelines or direct human interaction with content.
Information Panopticon 