January 15, 2024

Product Spotlight: Mark Pepper on Taxonomies in a CCMS

Share

A taxonomy in a component content management system (CCMS) is a way to categorize and label content so that it is easier to find and reuse. There is no single solution, however, to how an organization can create taxonomies for its content. Mark Pepper, Information Architect at Paligo, describes some of the use cases and best practices for working with taxonomies.

Mark has more than 25 years of experience in information architecture, knowledge management and technical communication. When giving presentations about what a taxonomy is, he often starts with this question for his audience: Is coffee a beverage or a soup? Depending on the criteria you apply, he says, it could be either. And that’s where the work with taxonomies, and categorizing content, starts.

Why is taxonomy one of your favorite subjects?

Mark Pepper: It’s because of what you can do with taxonomies. A taxonomy feeds into your metadata, which feeds into automation, which feeds into dynamic content – it’s an essential part of an intelligent system for content. Taxonomies enable you to properly categorize and map out all the features and functionality in your system.

What are taxonomies and taxonomy tags in Paligo?

Mark: A taxonomy in a CCMS is effectively a blueprint. It’s a blueprint for how you want to categorize and label all of your information and pieces of content. When you plan out your taxonomy ahead of time, you can identify content based on an audience category, for example, or a product category, and build out all the subcategories within those categories. You use taxonomy tags in Paligo to add topics, publications and images to those categories.

Why are taxonomies useful?

Mark: There are a few different use cases for taxonomies. For technical writers, probably the biggest advantage of taxonomies is being able to find content. Let’s say you’ve got 10,000 topics spread across your entire CCMS. When you’ve labeled all of your topics with taxonomy tags, you can use a taxonomy filter to find content much faster than you could searching through a folder structure. This also has the net effect that writers are less likely to create duplicates of a particular topic, which speeds up their authoring.

Then there is the use case of taxonomies for publishing. The publisher wants to be able to reuse certain topics, and to do that in Paligo they can apply profiling – or filtering – and variables, which are based on the taxonomy blueprint and use taxonomy tags. When they publish, they will be able to use one particular topic multiple times in different publications based on, say, who the audience is, the product that the topic is about, and so forth. By using taxonomy to filter the content, you save time when publishing and don’t have to create multiple versions of a particular topic.

Taxonomies can also be used to add classes and meta tags to HTML outputs. When you publish, Paligo can turn your taxonomy tag name into an HTML class name. Using HTML classes based on taxonomy tag names makes it easier for users to find relevant content. This also means you can use your CSS to show topics differently in your HTML or HTML5 output.

How should people go about creating taxonomies?

Mark: There’s two ways of doing it. My usual way of doing it is to do taxonomy planning in advance before you migrate everything over into Paligo. Someone with knowledge of taxonomy, like an information architect or a database manager, can guide this planning. This will involve steps like examining existing content, identifying keywords that appear with a certain level of frequency, and finding patterns of use so you can create what I call category candidates – the actual categories you want to apply.

The other way of creating a taxonomy is more like a naturally evolving ecosystem. In this way, people are constantly adding labels, or taxonomy tags, and you collect those labels in a tool, such as Paligo’s Taxonomy Manager. The labels and categories that the overall group uses naturally evolve, kind of like a tribal knowledge system.

The naturally evolving taxonomy is more of an unstructured approach, and it takes a little while to develop, but you might get a higher adoption rate than you would with a prescriptive approach. I personally prefer the prescriptive approach, but sometimes if you’ve got a large group who may have many different ideas, and they can’t come to a consensus, the tribal knowledge model might work best.

What should people keep in mind when creating taxonomies and taxonomy tags?

Mark: When you’re trying to come up with names for taxonomy tags or labels, try to come up with names that are relevant both to the people who will be applying the categories and to people who will be using the content. If you provide just haphazard, ad-hoc names to the tags, it will make it much harder for people to know when they’re supposed to use them. This also makes it harder for people using the tags to build a system.

For example, if you just decide to label some taxonomy tags A, B and C, that’s not descriptive enough. When a programmer is developing a solution to integrate with the content, they will have no idea what that means, and they can’t build an appropriate solution. So getting good clear names for your categories is very important.

If you’re naming a taxonomy tag or category for a certain audience, for example, try using the actual job title associated with that audience, and make sure it is a title that is actually used by the groups you are working with. Then you might need subcategories of that job title based on certain regions, such as in one region the job might be called “engineer” and in another part of the world they might be called a “mechanic.” Thinking about naming, tags and categories in advance will make it much easier to design the taxonomy before you start implementing it.

What are some common mistakes people make with taxonomies?

Mark: Probably the most common mistake is reusing similar names, like different names with similar spellings, or making a name plural or singular. For example, you might have a tag or label for “operator” and another for “operators.” Although they’re both technically the same thing, people will not know which one to apply, because a decision wasn’t made at the beginning of the taxonomy process.

Another common mistake, and one of the things that people struggle with the most, is establishing criteria for a category. It’s like the example I give about whether coffee is a beverage or a soup. It all depends on the criteria you use. If you don’t know the criteria for a particular category, then you won’t know when to apply that category.

When I’m teaching taxonomy, I give the example of how to categorize the different features of a house, and that one category is “security” and another is “comfort.” So how do you categorize a window? It actually fits into both categories, since it provides comfort by keeping cold or warm air out, and it provides security by keeping people from entering your house. So in this case, you need to define your criteria more specifically, saying that the feature for “comfort” only applies to temperature regulation, and “security” only applies to something that provides alerts or alarms.

What is a good way to plan and use criteria for categories?

Mark: When I am working with taxonomies, I use a spreadsheet that lists categories and then has a column for criteria. This can be helpful when educating authors about which categories to use in documentation. They can read it and see that if something meets certain criteria, then they should apply a particular category. You could also list the criteria as part of a description within the taxonomy in Paligo, just as long as it is documented somewhere.

If an organization is using a naturally evolving taxonomy, do all their tags get out of control?

Mark: Very much so. Part of the problem is that people organize categories based on what we call a single node, which is very common, unfortunately. With a single-node structure, let’s say you have an audience category, then under that you have a subcategory for different types of audiences, then under that you have product subcategories, then under that subcategories for subject, and so on, creating a big tree. What you end up doing is replicating all your different categories across all the different subcategories.

Because the structure is based on a single node, you can only really apply one category at a time, as opposed to a multi-node architecture. In a multi-node architecture, the audience, the product and the subject would all have separate nodes, and you can apply each separately. This gives you an almost limitless number of combinations.

How does Paligo help organizations get started with taxonomies?

Mark: In my role as an information architect, I help clients learn how to use Paligo as a tool, and I also provide them with best practices for working with a CCMS. This means that I advise them on how to do content audits, create content plans, and develop taxonomies and workflows. We want to make sure they have a good understanding of the theories and best practices associated with Paligo. Getting a good grasp of taxonomy helps them reuse more content, save time, and publish faster.

Share