The traditional taxonomy is hierarchical. Thus, after it is
determined a taxonomy is needed, often it is thought that it should be designed
as a hierarchy. However, in practical terms, a hierarchical taxonomy might not
be the kind that is appropriate.
A taxonomy provides value (1) as a controlled vocabulary of
concepts to support consistent tagging and comprehensive, accurate retrieval of
content and (2) by having some organized structure of these concepts to guide
users to desired concepts. That structure is traditionally a hierarchy, but
increasingly we are seeing a slightly different structure, which is faceted.
Facets define different aspects, types, issues, dimensions, etc., by which content
may be classified and then organizes the taxonomy concepts (terms) into those
facets. Examples of facets could be document type, location, function, department,
audience, subject discipline, line of business, etc., as the needs of the
content dictate. It is certainly possible to have a hierarchy of concepts
within a facet, but with a well-designed set of facets, the addition of
hierarchy may no longer be needed.
 |
| Hierarchical Taxonomy Structure vs. Faceted Taxonomy Structure |
Recently I had a small consulting project where I was asked
to make recommendations and improvements on newly created taxonomy, including
putting the Topics into a hierarchy. There were only 68 Topics (besides other
facets). I made changes that involved over half of the terms, including deletions,
additions, name changes, and moving terms from/to the Industries facet, but in
the end, there were about the same number of Topic terms. However, although I
made significant improvement to the Topics taxonomy, I did not feel it was
needed or practical to put the terms into a hierarchy, even though the client
had initially made that request. The small size, the type of display, and the
nature of the terms were all reasons not to have a hierarchy.
Following are reasons not to have a hierarchy:
- The term set in question is not that large and can easily be browsed (even with some scrolling) without a hierarchy to organize it.
- The hierarchy will not display (or not display well) to the end-users, who might, for example just have a small scroll box or a type-ahead or auto-complete search on the taxonomy terms.
- It is not easy or possible according to hierarchical relationship standards to put most terms into a hierarchy. For example, the term set in question is a collection of common tags/keywords/topics that occur in the content but are not necessarily related to each other, so it would be difficult to include all of them in a hierarchy, and the only way to create a logical hierarchy would be to introduce additional broader/category terms which are not practical to use for tagging.
- Putting only some terms into hierarchical relationships results in a non-intuitive top-level display comprising both specific terms and categories (of narrower terms) at the same level.
- Your user research indicates that users (including taggers) prefer type-ahead or auto-complete search on the taxonomy terms, rather than drilling down through hierarchies.
When the taxonomy is displayed to the user through a scroll box,
and only a limited number of terms, such as 5-10 may be displayed at once in
the scroll box display, it’s easier for a user to scroll and select terms from a
list of 50-60 terms, if the terms are in an alphabetical list rather than in if
they were in a hierarchy. Actually, hierarchies are not designed to be scrolled
but rather to be expanded from top down in their tree structure. Expanding a hierarchical taxonomy (such as
clicking on plus signs next to terms), might be a feature in the taxonomy
management system or in the tagging interface, but it is less common in end-user
interfaces. Expandable tree hierarchies might not even be desirable in the
end-user interface, since it takes the user more time and effort to find a term
that way. Most end-users want to get to the content as quickly as possible
rather than spend time exploring a taxonomy.
A number of content management systems and the SharePoint
Managed Metadata Term Store support the creation of individual terms sets or
facets and hierarchies within those facets. So, for the less experienced taxonomist, it
may seem logical to make full use of a system’s feature to support hierarchical
taxonomies. Just because a taxonomy can be created as a hierarchy, however, does
not mean it always should be created as a hierarchy. I have seen awkwardly deep hierarchies created
by non-taxonomists in content management systems.
Hierarchies should be created if they serve a purpose.
Following are some likely purposes for taxonomies:
- Making it easier for the end user to quickly identify the concept they want for retrieving content.
- Educating users (such as students) on the hierarchical structure of a subject area.
- Providing context to terms for manual indexers/taggers so that they apply the correct term. (Such a hierarchy need not be displayed to end-users, though.)
- Providing the context of a broader concept to aid in auto-classification.
- Allowing a term to retrieve not only what was tagged to it, but also what was tagged to each of its narrower terms. (Such a hierarchy need not be displayed to end-users, though.)
Even if a pair of concepts has an inherently hierarchical
relationship between each other, according to thesaurus standards (ANSI/NISO
Z39.19 or ISO 25964-1), it does not mean that they must be put into a hierarchy in a taxonomy, if
you’ve decided to avoid creating hierarchies and especially if what you are
creating is a simple taxonomy and not a thesaurus.
