It has become more common to design faceted taxonomies than purely hierarchical taxonomies, as I discussed in a previous blog post. Faceted taxonomies integrate better with search, serve for filters and sorting, and provide a good user experience for both novices and subject matter experts. The main drawback is that not all kinds of content are suitable for facets. Another reason it seems that most newly created taxonomies created from scratch these days are faceted is that faceted taxonomies really need to be custom created, whereas hierarchical taxonomies, thesauri, and ontologies, can more easily be reused.
A hierarchical taxonomy or a thesaurus represents the topics of a subject area, and the topics are arranged hierarchically (and possibly with additional nonhierarchical, associative interrelationships). In certain subject areas (academic disciplines, medicine, law, economics, engineering, etc.), the same taxonomy or thesaurus may be used in multiple implementations, with perhaps modifications of the level of detail (depth) of the taxonomy used, especially if used for the topics of articles, news, reports, research studies, etc.
A faceted taxonomy is designed to support users’ interaction with the content based on subjects, names, features, and attributes. It’s not simply a matter of finding the most appropriate topics based on drilling down through levels of hierarchy or exploring related topics. The user selects from the faceted taxonomy to filter available content, whether initially or after executing a search to reduce the content set size. Facets for a faceted taxonomy in an enterprise content management system could be for department, document type, business function, market, location, and subject, and the concepts within each facet would be tailored to the content of a specific enterprise. Facets for an ecommerce taxonomy would be customized for the product category, and could be for size, color, user type, technology, and specific categories of product features. Both the facets and the concepts within the facets are custom-designed for the content. The following illustrations show how specific customized facets might be.
While hierarchical taxonomies can get quite specific, they are specific in only one area, subjects, and greater detail could be ignored when re-using an existing taxonomy. Facets can get detailed in various areas: subject, document types, events, locations, people, etc., but since facets often don’t have hierarchies within them, you cannot simply ignore greater levels of depth, as you could with a hierarchical taxonomy, if you had hoped to reuse parts of existing facets.
Aside from the matter of reusing taxonomies, there is also the matter of taxonomy design. It is possible, although generally not recommended, to design a hierarchical taxonomy for a subject area without first analyzing the content to be tagged/indexing (although, likely the taxonomy will need revising after tagging begins). It is not possible to design a faceted taxonomy without analyzing the content first. A faceted taxonomy is tied too closely to its content.
So, creating a faceted taxonomy is not an academic exercise,
but rather a part of a real-life content management and information retrieval
case. I teach a course in taxonomy creation where creating a faceted taxonomy is,
in fact, an academic exercise. So, the only to do that properly is to have a
clear definition and understanding of the hypothetical content, just as
hypothetical users (personas), are needed for user experience design. Designing
facets will also be covered in my upcoming half-day virtual conference workshop,
"Taxonomy 101," on November 12.