Knowledge Organization and Taxonomies

Taxonomies are a kind of knowledge organization system. I had explained this in a prior blog post “Taxonomies as Knowledge Organization Systems.” Since then, I have learned more about “Knowledge Organization” (KO), not just the systems (KOS), through the International Society of Knowledge Organization (ISKO) and its most recent international conference, held August 17-19 in São Paulo, Brazil.

Taxonomies in the Scope of Knowledge Organization

ISKO defines KO in an article in its online ISKO Encyclopedia of Knowledge Organization:

KO is about describing, representing, filing and organizing documents and document representations as well as subjects and concepts both by humans and by computer programs. For these purposes, rules and standards are developed, including classification systems, lists of subject headings, thesauri and other forms of metadata. The organization of knowledge into classification systems and concept systems are core subjects in KO.

Although “taxonomies” are not explicitly named in this brief definition, they definitely are a kind of “concept system,” and taxonomies are mentioned further on in within the long encyclopedia article on KO.

The introductory paragraph on KO in the ISKO encyclopedia entry goes on to explain two main components of knowledge organization:

The two main aspects of KO are (1) knowledge organization processes (KOP) and (2) knowledge organization systems (KOS). Knowledge organization processes are, for example, the processes of cataloging, subject analysis, indexing, tagging and classification by humans or computers. Knowledge organization systems are the selection of concepts with an indication of selected semantic relations. Examples are classification systems, lists of subject headings, thesauri, ontologies and other systems of metadata.

The distinction and relationship between knowledge organization systems (KOSs) and knowledge organization processes (KOPs) was also mentioned in conference presentations I attended.  

These two aspects of KO are relevant for taxonomies, too. When designing and creating taxonomies, taxonomists and knowledge managers should also consider the process of applying the taxonomies. The processes, I believe, go beyond merely type of tagging, which could be manual, rules-based auto-tagging, traditional AI methods (machine learning, natural language procession, and entity extraction), LLM-support with RAG or GraphRAG.  “Processes” include the workflow and the interactions of people in various roles with the taxonomies. This was not discussed in depth at the conference, but I would like to explore it further in the future.

Research in Support of Knowledge Organization

KO is a field of study and research, especially within the academic discipline of information science, and it is often put into practice by librarians. It is not, however, known as a field or specialty within business or industry, where instead the related fields include information architecture, knowledge management, and semantic modeling or knowledge engineering.

Thus, ISKO members and conference attendees are predominantly academic: professors, researchers, and doctoral students. There were a few other non-academic practitioners at the conference beside myself, including my co-panel speakers Joseph Busch (Taxonomy Strategies) and Marjorie Hlava (Access Innovations). There were also doctoral students considering future employment in industry instead of academia. The conference had an “applied” KO track, but most of the “applied” topics were presented by academic researchers. What was significant was that presentations considered actual KO applications, and thorough research had been done to come up with conclusions, often with quantitative analysis.  

This raised the issue for me of the relative lack of research to back up the methods used to implement KO systems and processes in companies and other organizations. Knowledge managers, taxonomists and related consultants follow “best practices” that they have learned from colleagues or managers, but whether these are really the “best” methods for designing and implementing a KOS and KOP is not certain. I believe that adopting certain research methods refined by academic researchers or even partnering with academic researchers may result in better KOSs and KOPs. Fostering more conversation between academia and industry in the area of knowledge organization is also the interest of John Kausch, whom I met at the conference, who is helping to plan a conference and invited me to speak for this purpose at Western University, Ontario, next June.

AI and Ethics in Knowledge Organization

AI was a dominant theme in conference sessions, including the second day’s keynote presented by Prof. Heather Moulaison-Sandy, “KO under Constraint: Equity, Integrity, and Infrastructure in an AI Era” and in the panel “AI and the Future of Research.” Rather than considering AI only in the narrow context of how AI is used to create taxonomies and other KOSs or how KOSs can support AI, a broader approach was taken when considering the research-support objectives of KO.  

In the opening the to the Applied KO track, ISKO president Prof. Thiago Henrique Bragato Barros noted that there were 16 papers in the Applied track dealing with AI, and he shared his observation that there was a more positive view of AI in this track (of “Dimension”) of the conference, including papers on AI enhancing KOS.

Even the standards panel on which I spoke was rounded out with the presentation on the multiple ISO standards dealing with AI that are being developed by the committee ISO/IEC JTC 1/SC 42 Artificial Intelligence, given by Prof. Marcia Zeng.

Ethics was another common theme for many presentations, especially considering the potential biases that classification systems may have. The first day’s opening keynote, presented by Prof. Widad Mustafa El Hadi, was titled “Ethics in KO Through the Lens of Epistemologies of Violence.” Although taxonomies may be subject to bias and ethical issues, I believe that is less the case for taxonomies than it has been for classification schemes, which are more rigid in their design.

ISKO and its International Conference

ISKO is a global organization with chapters in various countries or multi-country regions. It was founded in Germany in 1989 with the goal of being an interdisciplinary organization to unite professionals from information science, philosophy, linguistics, and computer science. In addition to the ISKO Encyclopedia of Knowledge Organization, ISKO publishes a scholarly journal called Knowledge Organization and its conference proceedings in Advances in Knowledge Organization.

ISKO holds a biennial international conference, while its chapters may meet more frequently or in alternating years. This year’s conference was in São Paulo, Brazil, and the vast majority of the attendees were from Brazil, even though the conference was conducted entirely in English. I presented both a 2.5 hour “Taxonomy Design Workshop” and a presentation on “Thesaurus Standards for Taxonomies” as part of a panel “International Standards for KOS Supporting Information  Retrieval and Machine Learning Assessment.”
The next international conference will be held next in Coimbra, Portugal, in 2028. 

The ISKO conference panel "International Standards for KOS Supporting Information 
Retrieval and Machine Learning Assessment" with moderator Maja Žumer, 
Heather Hedden, Marcia Zeng, Marjorie Hlava, and Joseph Busch

Generative AI for Creating Multilingual Taxonomies

Taxonomies enhance the capability to identify and retrieve desired content.  Automated translation (machine translation) expands the scope of access to information to content in other languages. Applying automated translation to the contented identified using taxonomies thus enables people to find content on the subjects they want and then have it translated if needed. To retrieve such multilingual content, however, a taxonomy must also be multilingual. Concepts in the taxonomy must have names/labels in different languages: the language of the user and the languages of the content so that it can be tagged to the content.

Creating multilingual taxonomies

Fortunately, the data model upon which most large taxonomies are being built and managed supports multilingual concepts. The data model standard SKOS (Simple Knowledge Organization System) supports bilingual and multilingual taxonomies, because it models “concepts,” not “terms,” which has been referred to as “things, not strings,” and concepts can have any number of labels (strings of text) to describe them: a preferred label in each language that is displayed and any number of alternative (variant) labels in any languages, which are not displayed but match user searches and text strings for tagging.

The fact that multilingual taxonomies are simple to support technologically does not mean that they have been easy to create with translations. Whether translation is done by human translators or by machine translation software, translating a taxonomy is not as easy as translating narrative text. Both human translators and automated translation tools, (using rule-based, statistical, or neural network AI methods) look at complete sentences and not just isolated words. Words may have different meanings depending on their use in a sentence, and the context of a sentence may call for a different synonym in the translation target language.

Taxonomies with their hierarchical relationships provide context for the meaning of their concepts, but this is not the same kind of sentence-based context that machine translation programs utilize. Human translators can look at the context of the taxonomy hierarchy, but it’s a much slower task than translating sentences (which can also use machine-assisted translation tools) and requires an understanding of taxonomies.  Relying on machine translation or human translators who don’t understand the purpose or subject area of the taxonomy can lead to errors in translating taxonomies.

LLMs for generating multilingual taxonomies

Now, AI, in the form of LLMs, has become available to help generate taxonomies (which still require human review). LLMs don’t just generate terms, but they generate the correct hierarchical relationships to other concepts, multiple labels (as synonyms) for the same concept, and even definitions for concepts.

LLMs go beyond traditional machine translation and take the existing hierarchy into account when generating a translated label for a taxonomy concept. LLMs also follow specific instructions (or “prompts”) regarding the purpose and nature of the taxonomy. LLMs can also be instructed to focus on the meaning of the concept rather than on a literal translation of the preferred labels and each of the alternative labels. While the preferred labels for a concept in different languages are close translations, the alternative labels are not translations of each other but rather refer back to the concept. Even the number of alternative labels for a concept will vary by language. Finally, definitions are generated based on the concept and not as translations of existing definitions.

I explained this in a little more detail in my prior blog post Generative AI and Taxonomies for Finding Information

LLMs for generating new taxonomies in different languages

LLMs can be trained on, access, and generate text in different languages. This means that LLMs can generate entire taxonomies or parts of taxonomies in different languages from the start (with appropriate human-created prompts), without having to translate an entire existing taxonomy into another language.

Although a monolingual taxonomy does not have the same benefits of retrieving content in multiple languages as does a multilingual taxonomy, sometimes a monolingual taxonomy is desired. If a taxonomist is not available to create an entire taxonomy in the language, and a taxonomy on the subject already exists in another language, then translating a taxonomy has been a method to create a monolingual taxonomy in another language. As previously explained, translation of a taxonomy is not ideal and is prone to errors if not done by a translator-taxonomist. Using LLMs with the involvement of a subject matter expert (not necessarily a taxonomist) will generate a better taxonomy than a translation.

When using AI to build a taxonomy, it’s still best to have the top level developed manually to serve the specific use case, to create certain branches manually that are specific to an organization, and to generate incrementally those parts of the taxonomy built with AI, with the subject matter expert approving/disapproving suggestions for concepts and alternative labels at various stages. What is significant is that a person who is a combined taxonomist/linguist/subject matter expert is not needed to create a taxonomy in each language. In this way, taxonomy creation becomes easier to do globally. 

LLMs and multilingual generation in taxonomy management software

Managing a taxonomy in taxonomy management software has many benefits, especially when managing multilingual concepts. Now taxonomy management software is beginning to include support for LLMs to generate parts or all of a taxonomy, and thus support is integrated into the taxonomy creation and editing workflow. One tool, Graph Modeling from Graphwise, has now (last month) added the feature taxonomy generation in different languages to its Taxonomy Builder generative AI component. You can generate a monolingual taxonomy in any configured project language, and you can generate additional language versions of a taxonomy (creating a multilingual taxonomy) by generating concept preferred labels, alternative labels, and definitions, through LLM generations, not as direct translations. This essentially eliminates the need to translate taxonomies.

Generative AI and Taxonomies for Finding Information

Generative AI (GenAI) and Large Language Models (LLMs) have provided numerous solutions in many applications. The original public application of question-answering, popularized by ChatGPT, has become ubiquitous and has changed the way people search for information on the web and more recently inside the enterprise as well. Instead of keyword searches, people are submitting full sentence questions that can be refined. Full sentence queries allow for complex questions beyond just retrieving information “on a subject.” The system’s chat-type responses with suggestions on how to refine the query are especially useful and have improved the user experience of conducting searches and getting results. 

The question has arisen: “Why do you still need taxonomies and semantic tagging when AI could do all of that automatically?” Although GenAI has improved the experience in getting answers to questions, the accuracy and consistency of the results can be lacking. As taxonomies have enhanced traditional enterprise search results, taxonomies can also improve GenAI query results.

 

 

The Value of Taxonomies in Search and Findabililty

In the digital space, search engines at first seemed to compete with taxonomies, but soon it became apparent that search alone had short-comings. The same term with multiple meanings or the negation of a term results in false search results. On the other hand, the existence of synonyms for the same concept results in not retrieving (missing) desired results that are described with a different synonymous term. Furthermore, the search box by itself does not allow users to refine or expand their search results. 

Taxonomy concepts and semantic tagging for what content is about, not merely the mention of text strings, achieve better search results. Taxonomies bring together different synonyms or names of the same thing. Additionally, the display or partial display of taxonomies, as browsable hierarchies, filtering facets, or term matches to search strings in drop down (sometimes type-ahead) lists, have given users more control over search and more confidence in the results. Hierarchy can also be utilized in information retrieval, whereby a concept retrieves not only the content it has been tagged to but also the content that has been tagged to each of its narrower concepts. 

The Value of Taxonomies in Supporting Generative AI and LLMs

Like search, GenAI can be implemented without taxonomies, but GenAI combined with taxonomies for an enterprise implementation yields better results. LLMs work with patterns and predictions, and they do not always resolve synonyms. If you query “What are the leading U.S. pharmaceutical companies?” and “What are the leading U.S. drug companies?,” you don’t get identical results, although the answers are similar. 

When querying internal, enterprise information or data, a higher level of accuracy is expected and needed, and synonyms need to be made explicit. This can be done through a taxonomy, which the LLMs can reference when Retrieval Augmented Generation (RAG) is implemented, which reduces hallucinations, contradictions, and inconsistencies. 

Other taxonomy features than the synonyms may also be leveraged with RAG. Relationships between concepts (broader, narrower, and related) in the taxonomy can extend the retrieval. The hierarchy feature of a taxonomy also serves LLMs by providing context and thus more specific meaning for concepts through their hierarchical relationships. Furthermore, there may be terminology used uniquely to the enterprise, which an LLM wouldn’t know, such as “active customer.” Adding definitions to taxonomy concepts is useful both to the LLMs and to the human users. 

Data-heavy organizations that implement LLMs internally combined with a custom taxonomy at the enterprise level usually opt to go a step further and implement GraphRAG. GraphRAG combines LLMs with a knowledge graph, which comprises a taxonomy, ontology, and linked instance data in a graph database. This way, the LLMs can make use of the explicit semantic relationships in the knowledge graph, which support complex, multi-component queries. Because of their support for GenAI and LLMs using RAG or GraphRAG, taxonomies and semantic tagging are more relevant than ever.

 

Taxonomies can also improve the reliability of AI agents. They have been used to provide context for Copilot agents on an organization's terminology. Additionally, SharePoint Knowledge Agent uses AI-assisted metadata extraction to automatically classify unstructured content and map it to an organization's taxonomy.

Using Generative AI to Create Taxonomies

The next obvious question is “Can you use GenAI and LLMs to generate taxonomies?” Yes, you can. Taxonomies, however, are more complicated and nuanced than they might seem. Taxonomies should be customized to the content and data they will be used for, the end users’ needs and expectations, the use cases or purposes they will serve, and front-end application requirements. You would need to provide very detailed and lengthy prompts just to get started.

The best approach is to use GenAI for a taxonomy selectively. You may generate selected parts or branches of a taxonomy (such as topics, trends, technologies, or regulatory framework), but not for an organization’s own products, services, departments, or offices. 

GenAI is also suitable for various sub-tasks of taxonomy creation, such organizing a flat list of terms into a suggested hierarchy, suggesting alternative labels (synonyms) for a concept, suggesting narrower concepts for a concept, generating definitions for concepts, or explaining the relationship of two technical concepts to each other (broader/narrower inclusive, related and overlapping, or synonymous).

You can also use GenAI to generate a suggested starter taxonomy to use as a source for ideas and inspiration without adopting most of it. In any case, the specialized role of custom taxonomy should always involve human-the-loop interaction, instructions, review, and editing.

Taxonomy management software vendors are beginning to incorporate LLMs into their products to assist with the auto-generation of taxonomies or parts of taxonomies that their software manages. The vendor with the most advanced feature is Graphwise. I’ve had the opportunity to try out the Taxonomy Builder feature, which is integrated into Graphwise's Graph Modeling taxonomy/ontology management tool. You can read more about it in “How AI and Taxonomy Builder Support the Building of Taxonomies.”

Using generative AI to assist in the creation of custom taxonomies accelerates the process and supports taxonomy best practices with which project owners or subject matter experts may not be familiar. It also helps skilled taxonomists create taxonomies in subject domains in which they lack expert knowledge.

The Role of Taxonomists with AI

AI has led to the decline in certain information management jobs but not others. The role of professional content indexers has definitely declined with AI (not even GenAI) over the past decades. I know, as I used to be an indexer. Human tagging as a task, not a job role, continues to a limited degree, but increasingly the task involves reviewing and accepting/rejecting automated tagging suggestions.

The role of taxonomists will probably not decline, but will change. The need for taxonomies is growing. With GenAI, professional taxonomists are able to create taxonomies faster, so the cost of taxonomy creation is going down. (The LLM subscriptions are already being paid for other enterprise uses.) The use of GenAI to help create taxonomies also make their creation more feasible for those who are not taxonomists. Experienced taxonomists are still needed to provide initial guidance and ideally review and feedback. 

The role of taxonomy consultants, as myself, will likely also change. Instead of taxonomy project consulting engagements that last many months with intensive information gathering and numerous stakeholder interviews, followed by manual taxonomy creation with iterative reviews, more consulting engagements will involve helping design the start of the taxonomy, guiding clients to use AI, providing feedback, and developing the taxonomy governance plan.

Taxonomists are identifying more ways to utilize GenAI in their work. I will write another blog post on that at some point in the future, and I will be chairing a panel of taxonomists using GenAI at the next Taxonomy Boot Camp conference in Washington, DC, November 16-17, 2026.

Is a Taxonomy an Ontology?

At last month’s Knowledge Graph Conference, in addition to knowledge graphs and graph databases, there is a growing interest in ontologies, but the role of taxonomies does not seem so well understood. For example, in one presentation I attended, it was said "you get synonyms/alternative labels into a knowledge graph via ontologies," rather than mentioning taxonomies. More than one person asked me: isn’t a taxonomy a kind of ontology?  

The fact that, technically, SKOS (the data model for interoperability used for taxonomies) has been designed as upper ontology, can lead to the conclusion that all taxonomies modeled on SKOS are then domain ontologies, as they are instances of the SKOS upper ontology. However, that is a more theoretical way, than a practical way, to look at taxonomies.

When I write or speak about taxonomies, I aim to be practical. While theoretically a taxonomy is a kind of ontology, in practice it is not, and maintaining a distinction helps clarify how each a taxonomy and an ontology can improve on each when they are combined.

If you are an ontologist and see everything through the lens of ontologies, then you probably consider that a taxonomy is a simple type of ontology that merely does not utilize all the features of a full ontology. If an ontology is simply defined as a knowledge model that has classes (things), relationships between the things, and attributes as properties of the things, then, yes, a taxonomy is a kind of ontology. It has concepts, hierarchical relationships, and often other attributes for concepts, that typically merely definitions, scope notes, or other notes.

The problem of calling any taxonomy an ontology is that the benefits of semantically enriching a taxonomy with an added ontology or extending an ontology with a taxonomy might not be well understood. We add an ontology to a taxonomy in order to provide customized semantic relationships and attributes of all kinds. Additionally, basing the added ontology on OWL (Web Ontology Language) enables capabilities of inferencing and reasoning.

Furthermore, saying that a taxonomy is an ontology could lead to less than sufficient attention to the taxonomy features that ontologies alone lack. These features include alternative labels and hidden labels that match variants in both tagging and user searching, equivalent foreign language labels for concepts, concept schemes that can be implemented as search facets, and distinct fields for definitions and different kinds of notes that are standardized for interoperability.

If following the Semantic Web’s stack of data model recommendations, then a taxonomy can be defined as what is built on SKOS (Simple KnowledgeOrganization System), and an ontology is defined as what is built on RDFS(RDF-Schema) and OWL (Web Ontology Language). I find that a very clear explanation of the difference between taxonomies and ontologies to those who are familiar with ontologies. These different data models may be integrated within the same knowledge model, and that’s how we get taxonomies extended with ontologies or ontologies extended with taxonomies.

We might call taxonomy-ontology combinations “knowledge models” or “semantic models.” If the model has mostly taxonomy (SKOS-based) data, such as a large taxonomy with a little ontology added, it is best called a taxonomy, and if the model has mostly ontology (RDFS and OWL-based) data, such as a large ontology with some taxonomy  data, it is best called an ontology.

The organizers of the Knowledge Graph Conference understood the distinct role of taxonomies in knowledge graphs and thus welcomed me again to present a tutorial specifically on taxonomies.

Hierarchies and Attributes in Taxonomies

One of the challenges in creating hierarchical taxonomies is that there can be multiple ways to categorize concepts and thus design hierarchies. There are multiple methods to deal with this, including polyhierarchy and facets. Now that taxonomies are more often extended with ontologies, attributes can also be used for additional “classifications” of things.

Dealing with multiple hierarchies

The traditional method of dealing with multiple methods of categorizing concepts has been to put the concepts into a “polyhierarchy,” which means the concept has more than one broader concept, and thus belongs to more than one hierarchy.  The occasional polyhierarchy is acceptable, but if a polyhierarchy becomes extensive (numerous concepts belong to the same two hierarchies) due to different methods of classification, this does not serve the purpose of helping users find the concepts and tagged content desired. When everything is in a polyhierarchy, the guiding purpose of a hierarchy gets lost.

When the issue is multiple classifications for things, then what is known “faceted classification” is often the answer. A faceted taxonomy design involves designating a facet for each method of classifying things by. For example, products may have facets for brand name, product type, functional use/application, industry market, user type, etc. Each of these could be a facet for products.

Sometimes, however, there may seem to be more possible ways of organizing or classifying something than are practical for facets. It could be within a facet. For example, if you have a facet for product type, you could further classify the product types by product family, by  generic product type (narrower “is a” sub-type of the broader), by broader system of which they are a component (narrower is a part of the broader), by size, or by a certain key feature or characteristic.

Recently on a project, a client suggested an added level of hierarchy within the facet for named product models for a classifying feature that impacted the product size. The problem was that this would combine named entities (proper nouns) of product models and generic types within the same facet. This combination should be avoided in facet design, because facets enable users to search and filter by different methods, such as either by name or by type, and there are scenarios when users would choose one over the other. Combining types and named entities in the same facet can cause confusion. This is where an ontology model may be the solution.

Ontologies for further classification

Ontologies enable customized relationships between classes (which tend to be the same type of high-level grouping as a facet) and customized attributes for members of classes. When we think of ontologies, we usually think of the custom relationships, but custom attributes can support what could be considered “types.” These “types” might have been extra hierarchies, and thus attributes provide a solution to the multiple classification problem. 

If multiple methods of hierarchical classification seem to be overlapping, you should consider making one or more attributes instead.  In my recent consulting case example, what the client originally proposed as top concepts for grouping product models (as a classifying feature impacting the product size), we decided would work better as an attribute of the product models. So, the facet would contain only named entity product models, and the hierarchy would be by model family only.

When an ontology is defined as a formal naming and definition of the types, properties and interrelationships of entities in a particular domain, we might think we have to define everything in the domain, and thus creating an ontology is a large, complex project. Often, what we need is only “some” ontology. While using the features, rules, and data model of an ontology, we need to define only the types, properties, and interrelationships that need to be defined for a business purpose.  This could be defining just a few custom attributes (properties) without even adding any custom relationships.  

More information about attributes in is my prior blog post. "Taxonomies and Attribute Data." 

Examples

In the prior example, the product model feature had originally been proposed for the hierarchy for the purpose of “grouping,” because users might want to look up the product models by that feature. If implemented in a knowledge graph, the attributes, managed in an ontology, will also support users looking up entities by their attributes.  So, the hierarchical design is not necessary.

Any “groupings” of named entities (by region, size, role, etc.), should be reconsidered as attributes of the named entities. Other examples are groupings of vehicles by engine type, which could have engine type as an attribute instead, or groupings of appliances by energy type, which could have the fuel type as an attribute instead. So, instead of Electric cars narrower to both Cars and Electric vehicles, Electric, Internal combustion, and Hybrid would be attributes for Cars. 

Conclusions

Shared data model standards based on RDF (Resource Description Framework) and the use of dedicated taxonomy/ontology management software that combines taxonomies with ontologies make this solution of using ontology features to resolve multiple hierarchies easy to attain. Instead of thinking that we could extend a taxonomy into an ontology in the future, we should be thinking of how to design a knowledge model now that best serves the body of knowledge and the users.