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.