Taxonomy Hierarchy Levels

A taxonomy comprises a hierarchy of concepts (terms), and those hierarchies can be considered to be in different levels. In actuality, levels are somewhat artificial, and its important not to think of levels too strictly. In some taxonomies the levels are even named (for example: Domain, Category, Subcategory, Topic), but I would caution against such a practice.

Why we may tend to name levels

The most famous taxonomy, the Linnaean taxonomy of organisms, has well-known names for each of its hierarchical levels: Domain, Kingdom, Phylum, Class, Order, Family, Genus, and Species. There are issues, however, with this named-level system, though. In some cases, a Family may contain only a single Genus, and/or a Genus contain only a single Species (such as Homo sapiens). In some cases, a Species may have such variety within it, which we wish to describe, that we have created names for subspecies or other deeper levels (such as for dog breeds). For a digital navigation or information taxonomy of concepts, it would be considered bad style for a term to have only a single narrower term (as Homo sapiens). A term should have no narrower terms or at least two narrower terms, but not just one.

Besides the legacy of the Linnaean taxonomy, we may think of designated levels of a taxonomy, because the most common tool of developing taxonomies is MS Excel. In Excel, each column is used to designate a deeper hierarchical level, broader to more specific, from left to right. People may feel compelled to designate column headers (a typical thing to do in spreadsheets), whether as names or merely as Level 1, Level 2, etc. Excel is not intended to be taxonomy management software, and all dedicated taxonomy management software tools do not support the default naming or numbering of hierarchical levels, since there is no need for it in a taxonomy.

Why we should not name levels

Unlike the Linnaean taxonomy, the goal of a digital navigation or information taxonomy of concepts is not necessarily to classify concepts, but rather to arrange concepts (terms) in logical hierarchical relationships, so as to help guide the user to find the desired concept (which in turn is linked to content). A classification system (such industry classification codes or the Dewy Decimal system), which also has enumerated levels, is often considered a different kind of controlled vocabulary from a taxonomy.

A distinction needs to be made between hierarchical relationships and hierarchies. A good taxonomy or thesaurus design practice is to create hierarchical relationships between terms where they are logical: when one terms is a specific type or an integral part of another term, so users find narrower terms where they expect them. The extension of multiple hierarchical relationships, particularly when terms have both broader-term and narrower-term relationships, naturally results in the manifestation of hierarchies. But the resulting “natural” hierarchies are not consistent. There may be many levels deep in some places and only two levels deep in other places.  Terms that are on the same “level” may have relatively different degrees of specificity. I recently created a taxonomy for a discipline in which terms that were the equivalent of textbook courses ranged everywhere from the top to the fourth level. Fortunately, I was not constrained to have course as the first level.

Sometimes a taxonomy owner wants to set a policy as to how many levels deep the taxonomy should be.  It is understandable to limit the depth of a taxonomy in some cases: a hierarchy of navigation for public site visitors who want to get to content in the fewest clicks, lest they leave the site; a hierarchy of categories whose labels are to be picked up by search engines (supporting search engine optimization); or a hierarchy within a facet with limitations on browsing.  But there is a difference between limiting the total levels of depth and designating what the levels are called and are supposed to represent.

Examples of problems from named levels

Designating the names or types of levels inevitably results in the inaccurate application of level names or terms at inappropriate or inconsistent levels. For example, for a taxonomy of job titles I worked on, the project owner proposed that the top level be called Occupations and the narrower terms to those be called Specializations. This often works, but not always. For example, with the term Electrician and its narrower term Electrician Apprentice. Electrician was called and Occupation, and Electrician Apprentice was called a Specialization. Although an Electrician Apprentice can be a kind of (narrower term of) Electrician, it is not actually a “specialization” of Electrician. Also, a unique specialized job title may not have a broader term type of job title, so it would have to be called an Occupation. For example, Endoscopy Technician was designated as an Occupation, as it lacked a broader term, whereas Nurse Practitioner was a Specialization, since it had the broader term of Registered Nurse.

In another example of a taxonomy of academic areas of study I worked on, I was told that the taxonomy could have only two levels and the top level would be called Discipline and the second level be called Subdiscipline. The levels and designations were based on content management and business needs.  Thus, while Marketing would normally be considered a narrower term to Business, both were Disciplines at the same level. Some of the Disciplines were very specific, such as Real Estate Law (since Law did not exist as a discipline in this case), and some of the Subdisciplines were very broad, such as Computer Science (because it had a broader term of Computing). I resolved that this was not actually a taxonomy, but rather a metadata property with its values structured into two levels.

Taxonomies naturally have hierarchies, but do not naturally have levels, which are an artificial layer that sometimes get imposed.

Categories, Tags, and Taxonomies in WordPress

When I upgraded my Hedden Information Management website to WordPress a few months ago, I took advantage of WordPress’s blog post feature and incorporated a copy this blog into the website (while also keeping its original location on Blogger.com). The difference between categories and tags in the different platforms became clear. Blogger.com offers only “labels” to its bloggers, although these are listed as “Categories” on the displayed blog. WordPress, by contrast, offers both “Categories” and “Tags.”  When I imported my blog posts to the WordPress site, the Categories in Blogger.com became Categories in WordPress, but none of the posts had any Tags. I then realized that some of these Category terms perhaps should be changed to Tags.

The difference between Tags and Categories is a topic I blogged on five years ago.  A simple comparison is that Categories tend to be broader than tags, and more documents get assigned the same Category, whereas Tags tend to be more specific with fewer documents assigned the same Tag. Conversely, a document typically has only one or two Categories but more Tags.  Categories can also be organized into a hierarchy with subcategories, but Tags tend to be unstructured.  However, Blogger.com does not offer the capability of putting its Categories into a hierarchy, which would be desirable, since the number of my Categories has become too great to browse easily in a flat list.

WordPress appropriately treats Categories and Tags in differently in the following ways:

• Categories, unlike Tags, have the capability of being put into a hierarchy, be selecting a “parent” Category for a given Category. The hierarchy displays both in the Dashboard and optionally on the site.
• While both Categories and Tags are displayed on each individual post (and are hyperlinked to a list of posts which share the same Category or Tag), and both Categories and Tags that can be generated as Tag Clouds, it is only the Category list that can be alphabetically browsed by the site visitor (if added as a widget to a page).
• Categories are required, whereas Tags are not. If you don’t assign a Category to a post it will automatically get assigned the “Uncategorized” Category.
• Category labels appear additionally within the default URL of the blog post in a file path between the domain name and the filename. For example, my blog post with the Category of “Metadata,” received the URL of www.hedden-information.com/metadata/metadata-and-taxonomies.
• The Category name also appears within the breadcrumb trail, if the site has one displayed on each page. Of course, some blog posts have multiple Categories, and only one of them can appear within the URL and breadcrumb trail, so WordPress assigns one of them by default.

Creating and managing Categories and Tags for posts is a default feature of WordPress that’s easy to do in the Dashboard of a site. Since I had recently imported dozens of blog posts that had Categories and no Tags, I especially liked the feature to selectively convert Categories to Tags (One can also convert selected Tags to Categories.)  I went through my list of Categories and converted most of those that were infrequently used into Tags. The Categories to Tags Converter is one of the default Tools available for Import, but it does need to be “imported” and “activated” to be available.

Additional features in taxonomy management in WordPress can be obtained through various free or premium plugins. This is the case if you want to create multiple taxonomies, whether as sets of Categories or Tags, or faceted taxonomies. The default Categories and Tags feature permits the creation of just a single Category set and a single Tag set. If your site has different types of posts, such as custom post types, or if you want multiple term sets by which to filter posts by different aspects (facets), then you would need to create custom taxonomies. It is possible to create custom taxonomies by writing code, but if you are not a WordPress developer, there are plugins available for creating custom taxonomies. The support of synonyms/alternative labels/nonpreferred terms for Tags is also a feature available only with plugins, in this case plugins that aim to support search.

I will be discussing these topics in a presentation “Taxonomies,Categories, and Tags” at the WordPress conference, WordCamp Boston 2018, on Saturday, July 21. If you are in the Boston area come join me!

Creating Subject Terms for a Faceted Taxonomy

Faceted taxonomies—those that allow users to limit or filter search results by selecting terms or attributes from each of several types/aspects—are becoming increasingly common. They are easy and effective for end-users with various abilities in searching. When it comes to designing facets, some of the facets and their terms for a content collection may be obvious: Document or Content Type, Location, Audience, Purpose, etc. Creating a facet for Subject, for tagging topics the content is about, however, can be quite daunting.

Some faceted taxonomies do not have a Subject facet. Product taxonomies, such as for ecommerce, don’t have Subjects, but rather product categories. Enterprise taxonomies, such as those used in enterprise content or document management systems, also typically don’t have a Subject facet, but rather they have detailed terms in the Document Type facet and may have facets for Business Activity/Function, Department, Line of Business, or even something for Life Cycle/Phase/Stage.

The Subject facet is important, and can be quite large, for taxonomies for tagging and retrieving of content in a collection, library, or repository of published articles, research studies or reports, manuals, presentations, speeches, educational/training materials, images, videos, etc. If a large number of terms are needed to adequately cover the breadth and depth of the content, the Subject facet may comprise its own internal hierarchical taxonomy or thesaurus.

Coming up with the numerous Subject terms is more work and may require a different approach than for the terms of the other facets, which may be based on user needs and expectations. The terms in the Subject facet need to be based primarily on the subject of the content items being tagged. Other techniques for developing taxonomy terms, such as stakeholder interviews and search query logs, are helpful for other facets, but not so much for Subjects.

A taxonomy is built in a combination of top-down (identifying facets and top terms) and bottom-up (identifying the individual terms needed for indexing) tasks. The Subjects are developed a little bit top-down but more bottom-up. The top-down approach for Subjects starts with identifying the subject domain and scope and then any primary divisions in that domain, based on familiarity with the subject area and the content collection. The bottom-up approach involves looking a numerous individual content items to determine the main topics they are about and developing terms for these topics.

Determining what content items are about and what terms describe is the activity of descriptive indexing. I prefer to use the word indexing than tagging here, especially in absence of a taxonomy/controlled vocabulary, which has yet to be created, because it is an analytical task. (See my earlier blog post “Tagging vs.Indexing.”) So, at this stage it may help to have someone who has experience as an indexer do test-indexing of a rather large, representative sample of the content. Guidelines should be established at the start, such as each document is to be assigned index terms for the document as a whole, not for each section, and that a document should be assigned no more than three Subject index terms, for example.

The terms will need to be individually reviewed so that similar terms can be considered for merging into a single concept (and alternative labels/synonyms might be created). To keep the number of terms more manageable for review, it’s best to review and edit the terms periodically, before completing the test-indexing of the entire sample set of content. Thus, developing the taxonomy of Subjects by means of test-indexing is an iterative process. You will probably see trends, patterns, and possibly subcategories emerge from the terms as you collect them. The initial terms that come out of test-indexing can be quite specific and then made broader later. It’s easy to edit specific terms into broader terms, while it is not possible to go the other direction without reviewing the content again. In some cases, you can identify the key terms from the tile of a document or the caption/description of an image, but often for text you need to read headings/subheadings and skim the text or look at an image.

Ideally, this test-indexing can be saved, so when actual indexing is done with the final taxonomy, the indexing work does not have to be repeated. But often this is often not possible. So, test-indexing should not be too thorough or laborious. Before I became a taxonomist, I was an indexer, so I am quite efficient at this task, and I enjoy it.

Keep in mind that a taxonomy should continue to get updated even after it is implemented. This is especially the case for the Subjects, as new content will introduce new topics not yet included within the Subject terms. Thus, the test-indexing need not be completely comprehensive. It is understood that more Subject terms will be added as needed later. What is important is that new terms are added only in accordance with established policy.

x