Tagging with a New Taxonomy

The benefits to information users of having content tagged with a taxonomy are great. They include increased accuracy and comprehensiveness of search results, speed and efficiency in obtaining results, the ability filter search results, the opportunity to explore and discover related information, greater confidence in the completeness of results, and an overall better user experience. The benefits are worth the challenges of creating a taxonomy, and the benefits should be worth the challenges of properly tagging with a taxonomy as well.

Often the greatest challenge to taxonomy adoption is the ability to tag all of the content with the taxonomy terms as intended. Issues include allocating resources for tagging, implementing a new content management workflow, establishing criteria and quality control for tagging, and tagging a large volume of legacy untagged content.

Tagging Resources

While taxonomy development has one-time project expenses (such as the hours of consultant or contractor), the ongoing tagging with a taxonomy requires an annual budget on top of some startup expenses, whether tagging is manual or automated. Manual tagging requires budgeting for the working hours, while auto-tagging typically requires an annual software license. Automated also requires some human involvement for quality checks and refinements of tagging parameters.

Which method, manual or automated, to choose depends on the volume and speed of tagging required, the nature of the content, and the need for accuracy. Automated methods are more cost effective for large volumes of content tagging and can tag more quickly. Automated (AI) methods can tag text or images, but the same tool/technology does not do both, so for mixed content, manual tagging may be a more practical and affordable option. Automated methods are also better for content of a consistent type (e.g. all resumes, all news, all technical support articles), whereas a diversity of content (e.g. everything on the intranet or on the public website), can be tagged more accurately if done manually. Manual tagging may not be as consistent as automated methods, but unlike automated tagging, it is rarely wrong. If 10-15% mis-tagged content cannot be tolerated, then manual tagging may be preferred.

Automated tagging is not free from manual labor. If tagging is done by machine learning, then the machine needs to learn from examples, and sample tagged content may need to be prepared and submitted to the system as such examples. If tagging is done by rules, then rules need to be written for most of the taxonomy concepts. Prebuilt starter taxonomies may be pre-trained or have tagging rules included, though, but they likely will need refinement. In fact, any auto-tagging needs to be tuned and refined as the content and the taxonomy evolve.

Tagging Workflow

Whether manual or automated, tagging content requires setting up new content management workflows. It needs to be determined who does the tagging: the author, the editor, or someone else. Unless trained professional indexers tag the content, tagging review by an editor may be desired.

While manual tagging can be done within the same system (some kind of content management system) where the content is stored, these systems usually don’t have the functionality of auto-tagging built in. Automated tagging is typically done by establishing an integration between the auto-tagging tool (which may be a module of a taxonomy management system) and the content management system and the setting up of a data “pipeline” for the tagging tool. Setting this up may require some additionally billed services of the software vendor.

Also as part of the tagging workflow should be a method for taggers or those who review automated tagging to be able to suggest new terms to add to the taxonomy, as they see new concepts in the content.

Tagging Standards

Establishing criteria and quality control for tagging begins with setting tagging policy and guidelines. This includes setting the policy regarding to what detail to tag, how many terms of each type may be tagged to a single piece of content, whether a certain taxonomy term type is required or not for tagging, and whether the tagging of certain terms should trigger the additional tagging of another term (such as a broader term). These policies can be set as parameters for auto-tagging. For manual tagging, some of the tagging policies can be system enforced, but other policies cannot be.

Tagging has both policies (rules) and guidelines (best practices/recommendations).  A policy, for example, would be the minimum and maximum number of tags permitted, whereas a guideline would be a suggested narrower range of tags.

Whether manual or automated, tagging should be occasionally checked for accuracy, as a periodic quality control function. Based on the results, revisions may be needed for the taxonomy, and/or the tagging guidelines/policies may need to be revised.

Legacy Content Tagging

Even if there is an established workflow for tagging newly added content, there is the challenge of tagging all the legacy content that is already in the system. It’s rare that a taxonomy is implemented before any content is already collected and made available for searching.

Automated tagging may be a good way to handle the backlog of untagged content. However, software is intended to be licensed for at least a year and be a part of the regular workflow, rather than for a one-time backlog tagging project. So, the long-term use of auto-tagging software needs to be considered.

If manual tagging only will be the selected method for the long-term, then you should consider the tagging services of a freelancer, contractor, temp, or intern (library science student) to take care of tagging the initial backlog of content. Freelance indexers can be found through the American Society for Indexing and indexing societies in other countries. They prefer to call the activity “indexing,” rather than “tagging.”

While taxonomy creation is a project, taxonomy management and maintenance are an on-going program, and it’s the same with tagging. Backlog tagging will be a project, but ongoing tagging is a related program, and should be related to taxonomy management and maintenance. Tagging should be an important part of an information and content management strategy and not an afterthought.

Taxonomies for Learning and Training Content

Taxonomies are primarily for tagging digital content to make it more easily found when users search or browse on taxonomy concepts. Content can be of various kinds: articles and research reports, policies and procedures, technical documentation, product information, contracts and other legal documents, marketing content, etc. A growing area of digital content is instructional or training content, especially corporate training for employees.

The need for taxonomies for training content

When an organization offers its employees a large number of training courses, it can be difficult for employees to find desired training. Having the training content tagged with controlled terms from a taxonomy makes it easier to find.

The training content may come from different sources and thus may come with different, inconsistent metadata already applied to it. An organization may have generic training (such as on diversity and information security) produced by a corporate training company, industry-specific training (such as anti-money laundering for financial services and retail industries) produced by a different training company, and company-specific training which is internally produced. An organization may also subscribe to an offering of business skills and technical skills training offered by one ore more third party, such as LinkedIn Learning. It may be very difficult to search across all these different sources.

Furthermore, simply searching on words in training course titles might not be effective, if topics are broad or the course titles are vague. For example, a search on “communication” may yield far too many results to sort through. A search on “writing” might miss a training course with a title of “Bringing out Your Voice” or “Use Plain Language.” Tagged with the concept of “Writing,” these courses can then be found.

Faceted taxonomies for training content

Sample faceted taxonomy for
training content in PoolParty

For the complexities of training content, a single topical taxonomy is not enough. There could be ambiguity as to the skill level or between training topic and training format. For example, the topic of “Manager training” is not clear as to whether it is for new managers or all managers. The topic of “Presentation slides” is not clear as to whether it is training on how to create presentation slides or if presentation slides is the training format/medium. This is where a faceted taxonomy can help. Facets are different aspects of content which can be combined as search filters.

Training content is especially well suited for facets. Examples of possible facets for training content are: Content type, Level, Role, Skill, Training Program, and Topic.  An example of taxonomy terms in each facet are as follows:
•    Content type: Video training
•    Level: Intermediate
•    Role: Customer support
•    Skill: Written communication
•    Training program: Upskilling
•    Topic: Timeliness

It’s important to keep in mind that facets should be mutually exclusive, so the same concept, such as “Customer support,” cannot exist in both the Role and the Skill facets. Distinguishing a role and a skill can sometimes be difficult. It important to separate out Role, though, because then there is the possibility to recommend training courses based on one’s Role.

Taxonomy facets are based on metadata properties, but there likely exist many more metadata properties than needed for the end-user to filter train content searches. Additional, administrative metadata properties should not be implemented on the front-end for course searches. These might include Organizational unit, Original source, Region, Access Level, etc.

Skills taxonomy sources and challenges

Developing a skills taxonomy facet has its own challenges. First of all, there are multiple goals of skills taxonomies. Enabling employees or their managers to find appropriate training is just one goal. Other purposes may be to describe job openings to found by candidates with matching skills, to find an expert with a desired skill to ask question of or have work on a project, or to map roles and skills to identify gaps and improve human resources strategies and professional development programs.

There are also varied sources for skills taxonomies. Managers and subject matter experts would list certain skills, which might differ from a list of skills proposed by human resources staff. A taxonomist, metadata specialist, or information architect working on a taxonomy would come up with a slightly different list of skills, probably not as detailed. Finally, there are external sources, but these might not be appropriate to a specific organization. The largest, best known published taxonomy of skills is ESCO (European Skills, Competences, Qualifications, and Occupations), but with 13,890 skills, it is much too large and detailed for any one organization. It might be best to start with any skills list that the HR department has and build it out further with recommendations from managers, but not as detailed as some subject matter experts might suggest. External sources could be consulted to fill in some gaps.

There is the potential to get too detailed in creating a hierarchy of skills, and some of the narrower concepts may end up being specific topics and not exactly skills. For example, a skill of project management could get narrower concepts for different project management methodologies and then various components of each methodology.  This is would not be appropriate for a skills taxonomy, although, if important, these narrower concepts could be included in a Topics facet instead.

Presentations on taxonomies for corporate training content

My most recent conference presentation and my next conference presentation are both about taxonomies for corporate training content.  On October 16, I presented at the LavaCon content strategy conference in San Diego “Leveraging Semantics to Provide Targeted Training Content: A Case Study,” which was jointly presented with PoolParty software proof-of-concept project customer Esther Yoon of Google gTech. In addition to some of the issues described in this blog post, I also discussed how facets can be customized and how roles and skills can be linked for recommendation, and Esther presented how the POC improved the discovery of training content for those in roles related to customer support.

On November 6, at Taxonomy Boot Camp conference in Washington, DC, I will present “Challenges in Creating Taxonomies for Learning & Development,” which will be jointly presented with Amber Simpson of Walmart’s Walmart Academy, also a PoolParty software customer. In addition to issues described here, I will also provide specific examples of challenges in creation a Skills taxonomy facet. The slides will also be made available afterwards.

Taxonomies for Digital Asset Management (DAM)

Taxonomies, with their origin in thesauri and library subject heading systems, have traditionally been associated with the tagging and retrieving of text content. The management and retrieval of multimedia content (images, video, audio, or other graphics files), on the other hand, has traditionally been served by metadata schema, reflecting the various attributes of the content, including digital rights. 
Metadata for text content has become increasingly important to make it “structured” and easier to manage. Meanwhile, taxonomies, with their richness in topical detail, hierarchical structure, and synonyms, have become increasingly important in making multimedia content, especially digital assets, easier to identify and retrieve.

However, the features and uses of taxonomies and descriptive metadata have somewhat converged, now that faceted taxonomies have become common. A facet is an aspect or attribute, by which the user may limit, filter, or refine a search or initiate a search selection. (Several of my past blog posts discuss facets, including "Customizing Taxonomy Facets.") 

Why taxonomies for multimedia content and digital assets

There is considerable overlap between multimedia content and digital assets, although they are not identical. A digital asset is something that is created and stored in a digital form that has value. The word “asset” implies it has value. So, not everything that is in digital form is an asset. Creative works in digital form, whether by in-house producers or licensed, are considered digital assets. Multimedia content tends to have value, so it tends to be considered as digital assets. If it needs to be managed and made available for retrieval and reuse, it can probably be considered a digital asset. If it needs to be managed and made available for retrieval and reuse, then assigning metadata and taxonomy terms is probably important.

1. Growing volume of digital assets

The main reason to move beyond simple controlled lists of terms/values in metadata properties (such as Type, Location name, Location type, Event/Occasion, Person type, Season, etc.) and include relatively large topical taxonomies for digital assets is to provide the ability to better limit search results in large volumes of content. The number of digital assets owned or managed by organizations has grown immensely, as varied media sources have become more common, not just for brand content but also for marketing, instructional, and technical content. Limiting search results from only a few broad topic categories is often not sufficient, and too many digital assets are retrieved.

A taxonomy provides further granularity of subjects which a digital asset depicts or describes. A granular hierarchical taxonomy could provide the terms for a single metadata property, such as “Subject,” or there could detailed taxonomies in more than one metadata property, to also include “Activity,” “Product category,” or “Occasion,” depending on the use case.

2. Varied audience for digital assets and the use of synonyms

Another reason to use taxonomies for digital assets is to better suit a varied audience of users. While it is digital asset managers who rely on metadata to manage the digit assets, various other users need to find the same assets: product and brand managers, web content editors, art designers, partnership and licensing specialists, and perhaps even customers. Assets are most valuable when they have wider uses, but in order to be reused by different people and departments, a detailed taxonomy helps.

A taxonomy is not only more detailed than a list of a few categories, but it is also usually enriched with synonyms (also called alternative labels or variant terms). This way, different people who may describe the same thing by different names will find the same concept and its tagged content. For example, synonyms could be “Bridal” and “Wedding”; “Infant” and “Baby”; “Botanical” and “Plants”; “DIY” and “How to.” Internal users and external users often have different preferred names for things.

3. Connecting both text and multimedia content across the enterprise

Applying a taxonomy to tag digital assets can also allow digital assets to be retrieved along with other content, text content, in other content management systems (CSMs). This would require that the taxonomy be a centrally managed enterprise taxonomy, and not just a siloed taxonomy within a single DAM system, and that more than one system are connected to each other (such as through APIs or integrations) or that a dedicated front-end enterprise search application is linked to content in their source repositories.  

While users often look only for digital assets that they know are located within a specific DAM system, other times users want to conduct a more exhaustive search on a subject. While most images and videos are expected to be in the DAM, along with some PDF files, other PDF files, presentations, and documents, and even some images and videos from other sources may be located in other systems. Taxonomies that can be linked to each other or a single master taxonomy managed centrally in a dedicated taxonomy management system, such as PoolParty, serving as "middleware," connected to the content in each of the systems, can enable comprehensive search and retrieval across the organization, especially if all the data is managed in a knowledge graph (explained in my last blog post "Knowledge Graphs and Taxonomies").

Tagging or keywording multimedia content and digital assets

Finally, there is the tagging component of taxonomies, which is often called keywording with respect to images. Digital asset managers must assign descriptive metadata to the assets they manage, which is not difficult if the controlled lists of available values are short. A taxonomy, however, may be large, so it can be a challenge to determine which subject terms to tag. 

For text-only content, the technologies of text analytics, including entity extraction and natural language processing, can be applied to enable auto-tagging. Image, video, and audio content had previously been considered unsuitable for auto-tagging, and thus less suitable for large taxonomies, but this is no longer the case.

There are new technologies and methods to enable auto-tagging of digital assets. Audio-to-text technologies enable transcripts to be created from audio and video files, and these texts can automatically analyze and tagged. Improvements in image recognition technology can enable images to be auto-tagged for their subjects. Human review of auto-tagging is still recommended, but that’s easier than tagging from scratch.

Taxonomy is what powers DAM

DAM systems do support taxonomies, so you should not hold back from creating a suitable taxonomy for your DAM content. To learn more about creating taxonomies for digital assets, attend the session “Taxonomy is What Powers DAM” on September 14, 2023, at the HS Events DAM New York conference. I will join three other panelists to discuss taxonomies for digital asset management: what taxonomies are, how to develop a taxonomy, how to do research for a taxonomy, and how to manage a taxonomy, especially for DAM applications. Register with the code SPEAKER100 for $100 off.

 

Knowledge Graphs and Taxonomies

Knowledge graphs have recently emerged as an additional and growing use of taxonomies. A knowledge graph comprises data extracted and stored typically in a graph database with an ontology to semantically link types of data, but usually a knowledge graph also includes a taxonomy, thesaurus, or set of controlled vocabularies to provide consistent labeling. As a result of this combination, people involved in knowledge graphs are taking an interest in taxonomies, and people involved in taxonomies are taking an interest in knowledge graphs.

The traditional and still primary use of taxonomies is to consistently and comprehensively tag and retrieve content, whereas the focus of knowledge graphs is to access and make connections among disparate data. Content tagged and retrieved with taxonomies includes pages in websites, intranets, content management systems; documents in document management systems; and images and video files in digital asset management systems. Knowledge graphs link together data which includes records in databases, customer relationship management systems, product information management systems, and other enterprise systems, and the values in cells in spreadsheets, referenced by their row and column headers. By integrating a taxonomy into a knowledge graph, users can then retrieve both content and data on the same subject together.

What is a knowledge graph? The first non-sponsored definition that pops up today with a Google search not from a vendor is from the the Alan Turning Institute, the U.K. national institute for data science and artificial intelligence, which provides the following explanation on its Knowledge graphs interest group page:

Knowledge graphs (KGs) organise data from multiple sources, capture information about entities of interest in a given domain or task (like people, places or events), and forge connections between them. In data science and AI, knowledge graphs are commonly used to:

• Facilitate access to and integration of data sources;
• Add context and depth to other, more data-driven AI techniques such as machine learning; and
• Serve as bridges between humans and systems, such as generating human-readable explanations, or, on a bigger scale, enabling intelligent systems for scientists and engineers.

From the taxonomy perspective, a knowledge graph is a combination of controlled vocabularies or a taxonomy with the semantic layer of an ontology, which adds custom semantic relations and attributes, plus specific instance data, which is stored in a graph database.  A knowledge graph thus extends the use of a taxonomy beyond content to also include data. From the graph data perspective, a knowledge graph is the gathering of disparate data, which has been extracted, transformed, and loaded (ETL) into a graph database, where it is linked with semantic relations provided by an ontology and described by terms in a taxonomy, and it can be queried and analyzed all in one place. 

GraphViews of SWC ESG Knowledge Graph

It is an important to the definition of a knowledge graph to include its purpose and not just its components. The purposes include providing a unified view of data, easy availability of information, easy integration of new data, secure interoperability, visualization of entities and relations, the possibility of discovery and insights through semantic relations, and the support for complex multi-part queries with quick results. With inclusion of a taxonomy, a knowledge graph can bring together both data and content on in and organization.

 

With such lofty goals, knowledge graphs should be an area of interest not just of data scientists and ontologists, but also of information professionals (including taxonomists) and knowledge managers. This is gradually becoming the case. Knowledge graphs emerged in the 2010, and became popularized with the Google Knowledge Graph introduced in 2012. Knowledge graphs were first introduced at the KMWorld (Knowledge Management) conferences in 2017 as "semantic knowledge graphs,” and were also first mentioned at the Taxonomy Boot Camp conference that year. This November, the KMWorld conference has more talks on knowledge graphs than before. When I proposed multiple topics for this spring’s Information Architecture Conference, the conference chair chose the presentation on an introduction knowledge graphs. I also delivered a similar presentation this year to the joint Special Libraries Association and Medical Libraries Association conference.

I will be giving an updated version of those talks, “Knowledge Graphs for Information Professionals” as a free PoolParty webinar on Thursday, August 17, 11:00 – 12:00 EDT, after which the recording will also be available.

Taxonomies for Technical Documentation

Taxonomies are primarily for tagging content for what is about so that precise content can easily be found by users, who browse or search on the taxonomy terms. The types of content tagged and implementations of taxonomies are numerous. One growing area of taxonomy use is technical documentation.

Technical documentation describes and explains the use or design of products or services. We refer to “documentation,” rather than “documents,” because the format can vary, including book-length manuals, multi-page PDF files such as white papers, content for printed product inserts or brochures, public website pages, and internal content management system pages.  Technical documentation has existed for a long time. It used to be published only in print, especially as manual, like books, so the tools of information findability were the table of contents and the index at the back of manual. Now that technical documentation is most often consumed online and always managed digitally, an alphabetical browsable index is not practical to create, maintain, or use. Furthermore, indexes also cannot serve multiple-use (multi-channel) content well.

Taxonomies for content tagging and retrieval

In contrast to creating an alphabetical index of terms referencing page numbers or linked to content sections, tagging content with a taxonomy, has several benefits.

Taxonomies provide a better user experience than indexes. While an index requires the user to browse a long alphabetical list of terms until the desired term is found, the browsing of taxonomies does not require the user to already know the name of the desired term. Taxonomies that are arranged in hierarchical trees allow the user to drill down from broad categories to a specific topic. Taxonomies that are arranged as facets allow the user to select displayed terms (often listed by frequency of tagged usage) grouped by various facets (aspects) to limit the search results. 

 

 Facets for technical documentation could be:

• User audience
• Content type
• Product (name or module)
• Feature or function
• Topic

The process of tagging with a taxonomy or other controlled vocabulary is also simpler than creating an index. Creating a back-of-the-book index involves not only determining important concepts, but also giving them names as terms, determining subentries if any, and creating cross-references. Only trained indexers can do this well. Tagging with a taxonomy, especially if the taxonomy is already well-designed, is not so challenging. Since the terms and their synonyms or cross-references have already been established, it’s just a matter of looking up the term that describes to concept. Technical content now tends to be managed in component content management systems (CCMSs), so the unit of content to be tagged is already designated as a component. (See my April blog post.) Thus, content managers, editors, and writers can competently do tagging themselves. Tagging with a taxonomy can also be automated.

An index is tied to a specific document or collection. The same taxonomy, on the other hand, can be used for more than just technical documentation but across the enterprise, such as for website and other marketing content, product information, and research and development. Consistent terms support more efficient and comprehensive information gathering, sharing, and analysis.

Taxonomies to serve technical documentation’s diverse users

Taxonomies are a useful information finding tool when content is being used by different kinds of users. The same, or parts of the same, technical documentation often have diverse users: product customers, prospective customers, technical support agents, consultant staff, product managers, engineers, etc.

• Taxonomy concepts have synonyms or alternative labels to reflect the preferred wording of different groups of users. Matches to even these synonyms can be displayed after a search string is entered into a search box.
  

  

  https://help.poolparty.biz documentation search on taxonomy concepts
  

  
  
•  The same taxonomy can be adapted to different user groups with different user interfaces. For example, exposing more metadata in an “advanced search” or displaying just a subset of a larger set of facets.
• Taxonomy concepts can be managed with labels in multiple languages, supporting the tagging and retrieval of multilingual content for users of different languages.

 
Events on taxonomies in technical documentation

I have found increasing interest in taxonomies at technical documentation events. While I have been writing and speaking about taxonomies for a long time, in the past year I have been invited to talk about taxonomies at several events and programs more focused on technical documentation.

Recent past events focusing on technical documentation, at which I spoke, with recordings available:

• “Indexes, Search, and Taxonomies: Paths to Findability” Society for Technical Communication webinar, June 2023  (recording available for purchase in late July)
• “Taxonomy For Delivering Targeted Technical Content” BrightTALK webinar, April 2023
  
• “From Document Search to Document Understanding” presented by Helmut Nagy, ConVEx, April 2023 (The recording of my presentation on knowledge hubs, is only available for conference registrants.)

Upcoming presentations of mine focusing on taxonomies and technical documentation:

• “Taxonomy Creation for Content Tagging” online workshop, Society for Technical Communication Tuesdays, July 18, July 25, and August 1, 4:00 – 5:30 EDT (Registration is still open.) 
  
• Taxonomy panel, ConVEx Ideas online conference, July 19, 12:00 – 1:30 pm EDT
  
• “Leveraging Semantics to Provide Targeted Training Content: A Case Study” LavaCon content strategy conference, San Diego and hybrid online, October 16, 1:30 – 3:00 pm PDT
  

 

 

Taxonomies for Content Components

The primary purpose of taxonomies is to support consistent topical tagging (indexing) of content and full and accurate content retrieval based on the tagged taxonomy concepts that the end-user selects. The unit of content that is tagged makes a difference in the retrieval results and user experience.  Users want to find specific content, such as a paragraph, a captioned image, a timestamp section within an audio or video file. This is not always possible. The traditional method of tagging is to tag the entire file, document, or web page, even if the specific topic with the desired information is only part of the larger file, such as a few sentences within a web page or document of multiple paragraphs. The user then spends time (or wastes time) trying to find the desired information in the larger file.

Content components

Fortunately, there are methods to tag and retrieve content at smaller units, such as a text section identified with a heading, within a longer document. These methods depend on having “structured” content, where sections are marked off using a markup language, most commonly Extensible Markup Language (XML). As XML is rather generic, there have emerged standards specifically for XML-based component-based content management, including DITA (Darwin Information Typing Architecture).

www.dita-ot.org

Structuring content was not originally developed for the purpose of detailed topical tagging/indexing and retrieval, though, but rather for the purpose of creating (authoring) and publishing content, especially to the web, more efficiently. Originally, the focus of structured content was on marking up the document style and supporting keyword tags for the entire document. The first content management systems (CMSs) were developed shortly after the web in the 1990s to facilitate the publishing of web pages, although later a distinction emerged be web content management systems and enterprise content management systems.

By the early 2000s, component content management systems (CCMSs) emerged, whereby content is managed in units (components) smaller and more specific than an entire document. CCMSs enable content publishing to be more modular and flexible, supporting content reuse, and making it easier to update content, by updating only the relevant components, instead of the entire document. CCMSs are especially used for creating technical documentation, but they are not limited to that use. Examples of CCMSs include Adobe FrameMaker, Documentum, Hereto, Kontent.ai, Quark, Paligo, Sanity, and Tridion Docs. While more precise tagging was not the original goal of CCMSs, it is a beneficial outcome.

Taxonomies and component content management

CCMSs, along with all CMSs, have come to support taxonomies and tagging better over the years. This includes both support for more taxonomy features, such as hierarchies and synonym (alternative labels), and support for importing and exporting taxonomies in standard interoperable formats. With respect to CCMSs, taxonomies can be built out to a greater level of detail, with concepts specific to the component topics of CCMS. However, whoever is creating the taxonomy should remember not to create concepts that are so specific that a concept is applicable to only a single component topic. A single taxonomy concept should retrieve multiple results.

CCMSs, along with all CMSs, can also connect to or integrate with taxonomies managed in dedicated taxonomy management systems, such as PoolParty. Since organizations tend to have multiple CMSs, each for different kinds of content and purposes, they are likely to end up creating multiple, separate (siloed) taxonomies with similar or overlapping concepts. Therefore, the best strategy for enterprise taxonomy management is to manage taxonomies centrally, either as a single master taxonomy or with multiple taxonomies linked together in dedicated taxonomy management software, which can connect to CMSs with APIs (application programming interfaces) to push the taxonomy out to the CMSs, including CCMSs. Additionally, prebuilt integrations of taxonomy management systems and CCMSs, such as PoolParty and Tridion Docs, are becoming more common.

There is also a growing interest in taxonomies at conferences dealing with component content management. Last October I attended the LavaCon conference for content strategy for the first time, where my pre-conference workshop on taxonomies was well attended. Two weeks ago, I participated in the ConVEx conference, where there is more focus on component content management than at LavaCon. (ConVEx was formerly the DITA North America conference.) In contrast to LavaCon’s two presentations on taxonomies, ConVEx had a track with the “taxonomy” theme and five presentations focused on taxonomies and another three presentations with topics related to taxonomies.

Component content management enables more targeted topic tagging and opens up more possibilities for rich taxonomies. Thus, as a taxonomist, I look forward to learning more about CCMSs and how they taxonomies can best be applied in these systems.