When to Design a New Taxonomy for a New System

Often organizations determine that a suitable time to adopt a new taxonomy is in conjunction with adopting a new system for its implementation, such as a content management system (CMS) or digital asset management system (DAM). They can budget taxonomy design and development services as part of the consulting services needed for the content migration and system implementation project, and they can improve and optimize the taxonomy for its new implementation and use.

There is the question of timing, though. Recently, a prospective consulting client asked me whether the new taxonomy should be developed prior to the selection and implementation of a new system or afterwards. Ideally, both the taxonomy project and the CMS or DAM adoption can happen simultaneously. However, the design and development of a taxonomy takes less time (typically 3-4 months) than the adoption of a new CMS or DAM. Altogether, a system selection, with a trial or a proof-of-concept project, implementation, data/content migration, and user training, can take 6-18 months.

Benefits of Taxonomy Development Prior to System Adoption

The primary benefit of developing a taxonomy prior to system adoption is that you can make it a system requirement that the new system supports the taxonomy that you have designed to best serve your users, your desired tagging method, and the nature of your content. These criteria should take precedence over designing a taxonomy to fit the requirements (or limitations) of a CMS or DAM.

Over time, your organization will adopt other systems, and the taxonomy should be suitable for multiple systems, rather than being system specific. Especially if you have an enterprise (enterprise-wide) taxonomy as your eventual goal, designing your ideal taxonomy first should be your approach. If one system cannot take advantage of all features of your taxonomy, another system may. There are also usually development work-arounds to get the full use out of your taxonomy.

Benefits of Taxonomy Development After System Adoption

A CMS or DAM has a variety of functions, and tagging and retrieval of content with a taxonomy in only one of those functions. Workflow management, rights management, authoring features (for CMS) and image/video editing features (for DAM) tend to matter more than taxonomy use among the requirements for a system. You can make “good support of taxonomy management and tagging” a requirement for your new CMS or DAM without getting into the specifics.

Adding features a taxonomy (such as polyhierarchy, related-concept relationships, end-user scope notes, different sets of synonyms/alternative labels to support each tagging and searching) if the system you later adopt does not support them is a waste of time and resources. It’s better to wait until a system in selected and implemented before fully designing a taxonomy.

Iterative Taxonomy Design Approach

When implementing a new taxonomy with a new system, the ideal approach is to spread out the taxonomy design and development tasks over the phases on the system selection and implementation process.

You should consider basic taxonomy requirements early in the system selection process. To do this, you might categorize different taxonomy support features as essential and nice-to-have. The method of tagging (automated, manual, automated with human review, and a mix) needs to be determined as both a system requirement and as a factor in the design of the taxonomy.

Then during the lengthy process of system testing and selection, information-gathering work for the taxonomy may take place. This involves stakeholder interviews, user focus groups or brainstorming sessions, content analysis, and review of existing/legacy taxonomies and other controlled vocabularies. Draft versions of portions of the taxonomy, without all features, may be created and reviewed, prior to the system selection decision.

After the CMS or DAM is selected and is in the process of being implemented the taxonomy design can be refined with features that the new system can support, and then the taxonomy can be fully built out. The new taxonomy can also be tested in the new system for its suitability for tagging and retrieval, and final enhancements are made based on the test results. The documentation of the taxonomy, including guidelines for its maintenance (a governance plan), should be started early in the taxonomy design process, but additional system-specific documentation is created after the new system is implemented.

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 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.

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."

Taxonomy Design for Content Management Systems

A very common implementation for taxonomies is in content management systems (CMS). The content managed in this kind of software can be diverse: office application files, PDF documents, image files, audio files, video files, and, in the case of web content management systems, also HTML and any kind of file to be published to the Web. The “management” this kind of software supports is also diverse: enhancing, annotating, tagging, categorizing, reviewing, approving, sharing, assigning, publishing, archiving, and deprecating of content. Finally, the users can be diverse: content creators, content managers, and anyone in an organization who needs access to a subset of the content.

Due to the diversity of content types and purposes, the metadata associated with each content item obviously plays a very important role in a CMS. As for taxonomies, in the context of a CMS, it is probably best to consider a taxonomy as a subset of metadata, although the distinction between taxonomy and metadata can get blurred. Metadata about content can be descriptive, structural, or administrative. Descriptive metadata comprises the attributes that help make the content item retrievable or findable, including title, author, source, date, audience, document type, and also metadata for what the content is about (abstract, keywords, subjects, etc.) Many of these metadata fields should be populated with terms that are on controlled vocabulary lists for each field. In some cases, such as the “subject,” the controlled vocabulary may be rather large and thus organized into a hierarchy, and thus constitutes a hierarchical taxonomy of subjects.  In other cases, various aspects of what content is about might be categorized into different metadata fields with controlled vocabularies, such as: industry, process, specialty, department, location, etc. As a result, a set of controlled vocabularies for each field, could be considered as a faceted taxonomy, with each of these descriptive metadata field functioning as a facet.

With this mind, the task of actually defining the descriptive metadata fields or taxonomy facets need to involve various stakeholders, including both users and other experts and managers. Users include the various people who upload content and will tag the content with metadata and taxonomy terms, and the various end-users who will browse and search for the content using the metadata and taxonomy. Other stakeholders to involve from the beginning may include content managers, metadata architects, content strategists, business analysts, and user experience designers.

A CMS tends to offer two methods of classification: folders and tags. Folders (which in a CMS tend to be “virtual” folders, not actual file directory paths) offer an intuitive user interface for users to put content into categories and then find the content. Tags, on the other hand, are appropriate for assigning all kinds of metadata. Typically, if a dominant means categorizing is identified through conversations with users, such as content type or subject category, this categorization scheme can be used for the folders, and then all other means of categorization and classification can be handled with the tags. 

Recently a colleague asked me which method I thought was best for associating subject disciplines with multimedia content stored in a repository where the system offered both options: put them into folders named for each discipline or assign metadata tags for the disciplines. The answer, of course, is “it depends.” It depends on:

• Workflow: Will the files always stay in this repository or will they “travel” downstream to other applications?  If the content will likely move to other systems, then tags are preferred.
• Taxonomy size: Is the taxonomy under consideration for folders large? A large set of folders may be cumbersome to browse through and more suitable for type-ahead lookup in a metadata field lookup table or search box.
• User preference: Do users who upload prefer to use folders or tags only? Do users who need to retrieve the content prefer to browse through folders or only search on tags?
• Categorization enforcement: Can you enforce users to assign descriptive tags? If you are concerned that they will not, folders will better enforce the use of the categories.
• Support for hierarchy: Will the system support a hierarchy of categories within the lookup controlled vocabulary lists for the tag fields, or are hierarchies only supported as folders, or neither? Then consider which fields would benefit most from a hierarchy.
• Support for synonyms: Do the lookup controlled vocabulary lists for the tag fields include support for synonyms/alternate labels. If so, and if the controlled vocabulary is large, then tags have the advantage over folders, which cannot have synonym labels.

After determining what part of the categorization system, if any, goes into folders, and what goes into tags, the next task is to figure out how many descriptive metadata tag fields to create. Issues include:

• What metadata can be assigned automatically and what must be done manually? If it can be assigned automatically (such as file format type or language by auto-detect software or maybe even subject category by use of auto-categorization software), that’s great, but manually assigned metadata should be limited so as not to make the task burdensome.
• What fields are users likely to search on in retrieval? You need to cover the basics, but there is no need for additional fields that users are not likely to use as lookup criteria.
• What method of classification is important to the users? “Subjects” is a catch-all field, but if users are always thinking of something else too, such Discipline or Product, then these should be pulled out into separate fields or facets.

Finally, when designing taxonomy and metadata for a CMS, the taxonomist should have use of a test data instance of the system to try out the implementation of the taxonomy in the CMS user interface. A taxonomy that looks good offline (in Excel or a taxonomy management system), might appear awkward within the limitations of a CMS’s user interface.