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.
