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 to Bridge Silos

There is increasing interest in organizations to “break down silos” of content and data. Silos may be different software applications, distinct web or intranet content, or merely different computer drives and folders. The goal is to enable search and retrieval across content that is stored in different content/document management systems and shared folders and the analysis and comparison of data stored in different kinds of database management systems, records management systems, and spreadsheets. This results in better, more complete information to enable more informed decisions and knowledge discovery, along with improved user satisfaction, while also saving time. Breaking down or bridging such silos was a theme of my two most recent conferences.

 

LavaCon: Connecting Content Silos

The 20^th annual LavaCon conference on content strategy, held October 23-26 in New Orleans, had the theme this year of “Connecting content silos across the Enterprise.” The conference had a number of presentations tied to the theme, 10 of which had “silos” in their titles. Two presentations I especially enjoyed were by leading content strategy consultants about how to connect silos.

Sarah O’Keefe of Scriptorium, in her presentation “From Silo Busting to CaaStle Building,” with a fairy tale castle metaphor, explained that completely unified content cannot be achieved, because CMSs are tuned to specific content domains, corporate websites accommodate different goals of different groups, content silos have their own delivery pipelines, and silos often match the organizational structure. Her solution was to provide Content as a Service (CaaS), or a “CaaStle in the cloud(s).” Silos are kept, allowing for unique requirements, and perhaps reduced in number, but are connected were needed.

Val Swisher of Content Rules, in her presentation “Creating a Unified (Siloed) Content Experience: The Importance of Terminology and Taxonomy,” explained that siloed content results in different user experiences for each silo. But silos are not going away, because there is no single toolset, particular content has its owners, and certain content may be considered special. Therefore, the user experience should be improved to “ensure that all content looks like it comes from the same company” and to “eliminate the confusion that users experience when they consume content created by various silos.” This is done by standardizing the content, the search, page layout, navigation, content types, terminology, and taxonomy.

At LavaCon, I presented a pre-conference workshop with the title “Using Taxonomies and Tagging to Connect Content Across the Enterprise.” While most of my workshop addressed the general principles and best practice for taxonomy creation, along with the basics of tagging, I did discuss a how centrally managed taxonomy, external from but linked to various content management systems and other applications or repositories of content, can bridge silos. Taxonomy management software positioned as “middleware” such as PoolParty, connects to these different content applications and repositories, and then the taxonomy is presented to the user in a single user interface.

Taxonomy Boot Camp: Taxonomy Breaking Down Silos

At the annual Taxonomy Boot Camp conference, held November 7-8 in Washington, DC, and co-located with the KM World conference, I spoke in a two-presentation session titled “Taxonomy Breaking Down Silos.” The idea is that taxonomies provide the connections to break down barriers between different systems and teams. I presented on taxonomy linking jointly with Donna Popky, Senior Taxonomy & Information Architecture Specialist, Harvard Business School. I explained the principles of taxonomy project linking, and Donna presented a case study of taxonomy linking using a hub and spoke method to link separate taxonomies managed by different business units with separate content repositories for different purposes at Harvard Business School. So, this was a case of creating a hub taxonomy linked to the various business unit spoke taxonomies.

The other speaker in the session, Rachael Maddison, Content Infrastructure Architect & Taxonomy Product Manager for Adobe Digital Media Experience and Engagement, presented on taxonomy adoption across corporate silos and not merely content silos. Collaboration plays a role in wider taxonomy adoption, and as Rachael stated: “Mapping or merging can’t happen until there is stakeholder buy-in.”

Over the years, my list of the benefits of taxonomies has grown. Linking data, content, and corporate silos are additional benefits. This can be done with a single, enterprise taxonomy or with multiple linked taxonomies. In either case, the taxonomy needs to be managed externally from any individual siloed application in a dedicated taxonomy management system. Taxonomies can then break down corporate silos and connect content and data silos.

Intranet and ECM Taxonomies

In designing a taxonomy for tagging and retrieving content in intranets or in an enterprise content management (ECM) system, there is a fundamental question of whether to strive for creating a single comprehensive taxonomy to be applied throughout the enterprise or to have multiple specific taxonomies for different sets of content and different groups of users within the enterprise, or both. This question involves not only issues of information usability and user experience but also a mindset, which could involve a goal of “breaking down silos” by having a single enterprise taxonomy or one of encouraging “democracy” among organizational units and letting them create their own local taxonomies or terms sets (with training).

The main advantage of a single, global taxonomy is to enable users to effectively search and refine/filter results across all the content within an enterprise system using the same parameters. Users then don’t need to know in which intranet site or sub-site the desired content is to be found. Users need only become familiar with a single taxonomy, not multiple. So, it becomes easier to use. Content can be better shared and discovered.

On the other hand, more, specific taxonomies can also be of value, providing more precise retrieval results by users who know where and how to search with them. In many organizations, there are very specific sets of documents, for which a specific taxonomy would aid in retrieval, yet they can be of value to any employee. For example, in an organization that conducts research, these could be research reports or profiles of experts. In an organization that provides services, these could be documents of service descriptions, procedures, and policies. In and an organization with a large sales operation, these could be all the documents that support salespeople. The design of a taxonomy should reflect the  nature and the scope of the content and the needs of all users. Content in specialized repositories (research reports, experts, service documents, sales support documents, etc.) ought to have customized taxonomies to more fully support the best options in retrieval. For example, a taxonomy for research reports needs to be detailed in research subject areas. A taxonomy for experts would include areas of expertise, departments, locations, and job titles. A taxonomy for service support documents needs to be detailed in types of services and document types and should also include a set of terms for market segment. A set of taxonomies in support of sales should likely include product categories, sales function or process stage, market, and customer type. Meanwhile, a “generic” taxonomy, to be used across the organization, might be based on departments and types of functions/activities, along with general document types and topics.

It may be unclear who should decide and how the decision should be made regarding global, enterprise vs. specific, departmental taxonomies. The decision should probably be left to those in the organization who lead knowledge management or content strategy. The IT department, which sets up the Intranet, ECM, or SharePoint  system may have influence in this matter, based on how they choose to configure the system.  There can also be uncertainty and ambivalence over which taxonomy approach to take. During my interview with stakeholders for a recent SharePoint taxonomy consulting project, a lead IT stakeholder said that there was no policy, but that they “encourage” departments to use the same topical taxonomy. Yet at the say time, they also “create a local classification, but don’t encourage a local classification.”

Approaches to intranet taxonomies

Let’s look more closely at the various options for intranet taxonomy design.

1. Create a general enterprise-wide taxonomy and various departmental-specific taxonomies.
Benefits: Taxonomies are suited to the content
Drawbacks: Has silos and less sharing. User outside of a department may not be familiar with the departmental taxonomy.

2. Create a single comprehensive taxonomy (or set of taxonomies/facets) to cover all the internal information needs of the organization.
Benefits: There is more sharing and ease of having a single taxonomy of terms for users to refine searches by.
Drawbacks: It is more difficult for tagging with a large and potentially confusing taxonomy, where sections of the taxonomy are irrelevant to some sets of taxonomy, and some terms may have been intended for one purpose but get used for another purpose.

Other options are more creative, and hopefully IT can customize the content management and search software accordingly to support them.

1. Create an enterprise-wide taxonomy, as a master taxonomy, which is both general and specific, and various specific taxonomies, and map the specific taxonomies, term-by-term, to the master taxonomy which includes all terms. Those who tag only need to use their appropriate specific taxonomies, but those who search, making use of the master taxonomy, can have a “federated search” experience allowing discovery and retrieval across the enterprise.

2. Create a single comprehensive taxonomy with branches that can be hidden from display to those tagging content which does not require the terms from those branches of the taxonomy. This makes it easier for those who tag, not being overwhelmed with a very large taxonomy, much of which is not relevant to their content, and contains terms which could potentially be confusing and misused.

As I was struggling with the problem with my current client on whether to make a large taxonomy (500-600 terms) available for tagging in all SharePoint sites, even though it was relevant to only a minority of the sites, the IT stakeholder informed me that for designated sites he could set the display of the taxonomy for tagging of just one top-level branch of the taxonomy and hide the rest. Although no more than one branch could be displayed in this method, which would impact the hierarchical design of the taxonomy, this was the best compromised solution in this case.

I look forward to sharing and learning more about taxonomies for intranets at the upcoming IntraTeam Event Copenhagen: The European DEX Conference, where I will be giving a pre-conference workshop "Taxonomy Design & Creation."

Engaging Others in Taxonomy Building

Whether you are building a new taxonomy from scratch or redesigning one based on an existing taxonomy, it’s important to engage other people in the process. There are two primary reasons:

1. getting input from those who will use the taxonomy, so that it will better suit their needs
2. getting buy-in and support from various stakeholders and users, so that it will continually be used, maintained, and funded

Even if you are the only person given the responsibility for creating and editing the taxonomy, and it’s no one else’s job to be involved, you should still seek the input of others.

It’s just common sense to get input from those who will use the taxonomy, although being respectful of their time in the process. If the taxonomy project can be stretched out over time, this means that asking for input does not happen too frequently.

Getting buy-in and support is an issue that is especially particular with taxonomies. People don’t always understand or respect the full benefits of a taxonomy. They may think that search alone or automatically generated keywords may suffice. Or they may prefer the simplicity of a search box. People responsible for tagging might prefer to avoid that task to save time and thus not adequately or correctly apply the taxonomy. Getting such people involved in the taxonomy creation process both educates them about the benefits of the taxonomy and gives them a sense of ownership by contributing to the process that is meant to serve them.

Others in your organization will use the taxonomy. If it’s for tagging and retrieving content internally, some people will use the taxonomy to tag content, and other people will use the taxonomy to help find content, but representatives from both groups of people should be invited to give input. If the taxonomy is to be use for public-facing content, those who will be tagging the content are still within your organization, and they should be consulted in the taxonomy design process.

Taxonomy consultants might lead 2-day taxonomy brainstorming workshops of stakeholders, conduct a series of interviews with stakeholders and users, and develop detailed use cases. While there is usually not the interest in demanding so much time of others when the taxonomy project has been assigned to a person on staff, the taxonomist should still engage other employees, at least at a minimal level. To get initial input, instead of in-person interviews, this could involve emailing a short list of questions to key users and stakeholders and the following up with a phone conversation to go over the answers. Draft versions of a starter taxonomy, which can be developed by means other than a brainstorming workshop, should be shared with stakeholders and subject-matter experts for feedback.

A rather technical taxonomy could start with asking the subject matter experts to submit lists of terms which the taxonomist would review with them and edit into proper taxonomy. In most cases, however, the taxonomist develops the draft starter taxonomy and then seeks feedback.

If you are not asking stakeholders to provide the starter taxonomy, where do you start? Someone asked me that question recently: “Where do I go to get my starter/basic/beginner list before I actually sit with staff?” I advised that you don't need much prior to talking with people. My recommendation, in the case of an enterprise taxonomy, would be to consider the following sources for draft taxonomy terms:

1. Folder names from shared drives
2. A prior attempt at creating a starter taxonomy, even if never implemented
3. Categories or tags set up in a content management system, whether or not fully used
4. Intranet/website site map or navigation menu labels
5. Product catalog top categories (as a starting point for a "Product" facet/Term set)
6. Org chart (as a starting point for a "Department" facet/Term set)
7. High-frequency use terms from search log reports

Include at least the two of these sources to share with people in meetings. I also recommend not editing them prior to initial meetings with people, but rather to get their input on this raw data.

Taxonomy work, is thus people-oriented work, like information architecture, in contrast to related fields of indexing and cataloging.

Deviating from Taxonomy Standards

In my last blog post, I suggested that enterprise taxonomies need not follow the standards for controlled vocabularies and thesuari (ANSI/NISO Z39.19 guidelines and ISO 25964-1) to the same extent as “traditional” discipline taxonomies and thesauri. I say this cautiously, though. Standards should not be ignored for any taxonomy, but rather followed in general, and any deviations made should be for good reason. Enterprise taxonomies (taxonomies custom-designed for the content and users of a specific enterprise, and for the entire enterprise) and also ecommerce taxonomies (taxonomies of products for sale) often have good reasons to deviate from standards in certain areas.

Hierarchical Relationships
An important part of the taxonomy standards are the criteria for creating hierarchical relationships. Hierarchical relationships should be one of three types: generic-specific, generic-instance, or whole-part. Any other relationship among posted/displayed terms is not hierarchical, but rather associaciative. A “good reason” to relate terms hierarchically even when they do not exactly meet the criteria, is when the pair of terms are clearly related, but the taxonomy does not include any associative terms. Enterprise and ecommerce taxonomies often are simple hierarchical taxonomies and do not support associative relationships common in standard thesauri. For example, the following two hierarchies are not correct by the standards, but the first may be acceptable in an enterprise taxonomy and the second in an ecommerce taxnoomy:

  Information Technology
   > Telecommunications
   > > Cell phones

  Cameras

  > Camera accessories

Plural/Singular
The standard is to use plural for terms that are countable nouns. The idea is is that when users select a term they will find multiple documents, records, or digital assets (in plural) indexed with or categorized by the term. Enterprise and ecommerce taxonomies, however, tend to be comprised of multiple taxonomy facets, whereby the user selects terms from a combination of facets. Taxonomy terms within facets then appear to user to be filters, scopes, aspects, or attributes, rather than simply a category of plural objects. For example, a document type facet might have terms in the singular describing the type of document: Article, Report, Form, Application, Interview, etc., all in the singular to answer the question “what kind of document.” The names of the facets themselves may also be in singular, rather than plural, so as to “limit by” a facet, such as: Document type, Location, Topic, Department, etc.

Compound Terms
The standards present criteria to consider in retaining or breaking apart compound terms. For example “A compound term should be split when its focus refers to a property or part, and its modifier represents the whole or possessor of that property or part.” (ANSI/NISO Z39.19-2005 section 7.6.2.1) While such guidelines are useful and certainly within the scope of taxonomy design, the highly customized nature of enterprise or ecommerce taxonomies obviate following such guidelines for compound terms. ANSI/NISO gives the example of aircraft + engines rather than aircraft engines, but aircraft engines, or other such compound terms, would be perfectly acceptable in an enterprise or ecommerce taxonomy. It is worth noting that both the ANSI/NISO and ISO standards state that these criteria are just guidelines and do not have to be strictly followed.

An enterprise or ecommerce taxonomy can be a challenge to create. Just because adherence to taxonomy standards may be less strict for a corporate or retail taxonomy than it is for a subject/discipline taxonomy, should not suggest that it is easier to design or that non-trained taxonomists can design it. Only with a good understanding of the standards would one know when and where it is acceptable not to adhere to a specific guideline.

Enterprise Taxonomies vs. Traditional Taxonomies

A book that I have been reading (Structures for Organizing Knowledge: Exploring Taxonomies, Ontologies, and Other Schemas, by June Abbas, 2010) got me thinking about the comparison between corporate/enterprise taxonomies and other “traditional taxonomies”. I found it intriguing that Abbas presents corporate or “professional” taxonomies in the same chapter on personal information structures. Thus, a corporate taxonomy could more aptly be an extension of a personal knowledge organization system, rather than the customization of standard taxonomy or controlled vocabulary.  So, how are corporate taxonomies or enterprise taxonomies (corporate taxonomies that are specifically for use enterprise-wide) different from traditional (library science type) taxonomies or thesauri?

There are, in fact, multiple ways in which a corporate or enterprise taxonomy differs from the traditional taxonomies or controlled vocabularies used in libraries or in particular subject disciplines. Enterprise taxonomies in particular are:

1.      Relatively small in size

2.      Multifaceted

3.      Customized to an enterprise’s content

4.      Customized to an enterprise’s users

5.      Relatively informal

Size
An enterprise taxonomy tends to be relatively small in size with respect to the number of terms and depth of term levels. The size will depend largely on the complexity of an enterprise’s business (number of lines of business, for example), but the range of 1000-2000 terms in an taxonomy for an enterprise that has single line of business is typical. An organization may certainly supplement  this enterprise taxonomy with additional subject-specialized controlled vocabularies, particularly in the areas of research & development or product catalogs.

Faceted Nature
An enterprise taxonomy deals with a variety of content which is differentiated in more than one way, not just by subject matter. Content is typically organized and searched not merely for what it is “about” but also what its purpose is, what its source is, what type of content it is, and perhaps also for what market or customer type it is relevant. Thus, an enterprise taxonomy is usually organized into several facets to support faceted search or faceted browse (see my April 2012 post), which include: document type, file format, department or functional area, line of business or product/service category, geographical region, and market segment, in addition to a topical facet.

Content Customized
A corporate or enterprise taxonomy should be highly customized to an enterprise’s own unique content. While two companies in the same industry may have nearly identical products and services, their customer or member base could vary slightly, and they probably do not have identical organizational structures, procedures, and workflows. Thus, no two companies or organizations would have identical content. Organizations also differ in the quantity of different kinds of content they own and in the importance they assign to different types of content.

User Customized

Just as important as content-customization is user-customization. Corporate or enterprise taxonomies are designed to help an organization’s users (employees, and often also partners and customers) find content. Users include both those who upload/publish content to the intranet or content management system, often manually tagging it, and users who are looking for content. These are sometimes the same people and sometimes not. Also in consideration of the users, there may be a workflow or business rule aspect that is taken into consideration. Thus, the process of designing an enterprise or corporate taxonomy involves gathering input from users, via interviews and workshops. For this reason, the author Abbas has combined corporate taxonomies into the same chapter as personal taxonomies, because they are both highly user-centered.

Informal

Traditional discipline taxonomies (such as for living organisms), thesauri, book cataloging and classification systems follow industry standards for their design and construction, which can be quite rigid and formal. For general-purpose controlled vocabularies, there are the ANSI/NISO Z39.19  guidelines and ISO 25964-1 standard (see my March 2012 post), which allow more flexibility than library cataloging rules. The design of corporate or enterprise taxonomies should adhere to ANSI/NISO or ISO standards at a high level, but in practice, other practicalities and user needs and expectations should take precedence over a strict following of every detail of the standards.

Business Taxonomies

It’s difficult enough for professionals to come to a consensus on the definition of “taxonomy.” As for “business taxonomy,” it’s even worse. There are varying ideas of taxonomy, varying ideas of “business,” and varying ideas on what the connection should be, in addition to the scope and purpose. Is it a taxonomy used by a for-profit enterprise? Is it a taxonomy of business processes for use in any enterprise? Is it the same as an “enterprise taxonomy”?

Just as the term “taxonomy” has both a specific and generalized meaning, so does the term “business taxonomy.” The specific meaning of a taxonomy is a controlled vocabulary of concepts (terms) that are organized into a hierarchy, based on hierarchical relationships (broader/narrower, parent/child, group/member, superordinate/subordinate) between the terms.  The generalized meaning of taxonomy is any kind of controlled vocabulary or sets of controlled vocabularies (whether structured as lists, hierarchies, facets, thesauri, etc.) to support the organization and findability of content. The specific meaning of a business taxonomy, is a taxonomy that is specific for business use by dealing with business functions and processes. The generalized meaning of a business taxonomy is any taxonomy used by a business/enterprise, as opposed to a scientific discipline, to organize and manage its content.

I would caution that a taxonomy designed to define and describe business process and functions may not have the same objectives as the more common taxonomies whose purpose is to support the organization and findability of indexed content (documents, files, digital assets, etc.).  In fact, even the term “taxonomy” in its purest sense does not mean that it has to be used for content management. The original taxonomies, such as the Linnean taxonomy of animals, plants and other organisms, were not designed for indexing and searching content associated with each concept in the taxonomy. Similarly Bloom’s Taxonomy of educational concepts is not for indexing educational content but rather to define the scope of educational objectives. Thus, a taxonomy could be just for classifying its term/concepts/members for sake of better understanding of its members and their relationships. In this way, a business taxonomy, in its more specific meaning, with the focus on functions and processes, could serve the purpose creating a better structure of an organization and improving business processes. The users of this kind of business taxonomy are the officers and managers of an organization with a goal of improving overall management, rather than all content users.

Furthermore, the business functions/process taxonomy can be more generic, and the same taxonomy, such as a Sales, General & Administrative (SG&A) taxonomy, with modifications, could be used by different organizations. In contrast, a taxonomy for content management and retrieval, especially when it is product/service-focused, should be custom-designed and developed to reflect the nature of the content and the goals of its users. The larger an enterprise is, the more unique its particular business mix and content is. That’s why the largest enterprises tend to have taxonomists on staff.

Yes, the more generic “business taxonomy” and “enterprise taxonomy” are terms often used interchangeably. However, I prefer it when the term “enterprise taxonomy” is used to mean specifically a taxonomy (or set of inter-related taxonomies) that is intended for use enterprise-wide. This is an important designation, because within an enterprise, taxonomies are often siloed. Integrating them and designing a unified taxonomy that cuts across all departments to support the broadest sharing of content across the enterprise is an important goal of an “enterprise taxonomy.”

The term “taxonomy” might sound too technical, scientific for business owners and managers who don’t understand exactly what it is or what it can do. Calling it a “business taxonomy” is sometimes a sort of marketing technique of taxonomy consultants to suggest that a taxonomy is something standard for businesses and something the business needs. It often works, but ultimately the term “business taxonomy” has resulted in confusion as well.