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 taxonomy designLet’s look more closely at the various options for intranet taxonomy design.
1. Create a general enterprise-wide taxonomy and various 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."