Definition 

In taxonomy, a polyhierarchy refers to any hierarchical structure that allows a term to have multiple parents. (The opposite concept, monohierarchy, is used to describe taxonomies that do not allow polyhierarchy.) 

Polyhierarchy does not apply to two concepts with similar labels: 

Baseball equipment 

-Bats 

Animals 

-Bats 

…is not polyhierarchy; Bats refers to two different concepts and one (or both) should be disambiguated. Polyhierarchy only applies when the same concept appears in multiple places in a taxonomy. 

The rules for polyhierarchy are simple: a term may have two or more parents if and only if each parent fulfills the criteria for permitted BT-NT relationships. In other words, polyhierarchy is not a license to play fast and loose with the All-Some Rule: 

Animals 

-Cats 

Pets 

-Cats 

This is not a good polyhierarchy, as not all Cats are Pets. Proper polyhierarchy requires that a term—and all of its children—can properly be assigned as a child of each of its parent terms. A better way to model these concepts might be: 

Animals 

-Cats 

–Pet cats 

Pets 

-Pet cats 

Pet cats is a valid child of both Cats and Pets, so this arrangement is good polyhierarchy. 

Generally, polyhierarchy is useful and uncomplicated, as it presents an intuitive method of categorizing a term in multiple ways. This offers, for example, users browsing for topics or products multiple paths to find what they’re looking for without having to guess. 

Uses 

Most e-commerce taxonomies are polyhierarchical for this reason; consider the following structure: 

Apparel 

-Women’s apparel 

–Women’s shoes 

Shoes 

-Women’s shoes 

In this example, Women’s shoes has two parents: Women’s apparel and Shoes. If Women’s shoes does not have both parents, which one would be preferable? Either way, using a monohierarchy would potentially limit the ability of customers to quickly find Women’s shoes. It is only logical to have this concept (and the products or content attached to it) in both places. 

Polyhierarchy is also crucial for using taxonomies to build topic maps (like taxonomies outlining topics in a field of study or industry sector) more accurately. As many (or even, at this point, most) fields are interdisciplinary to some degree, polyhierarchy allows the accurate description of fields’ interrelations. 

Science 

-Physical sciences 

–Chemistry 

—Physical chemistry 

Physics 

-Physical chemistry 

Physical chemistry (distinct from Chemical physics, which also would have worked in this example) is a subfield of both Physics and Chemistry; any topic map taxonomy that selected only one or the other parent would be doing a disservice to the accuracy of, say, search or analytics on a content set tagged with these terms. That is to say: if I want to find (or count) all of the papers on any topic in Physics, and Physical chemistry is only a child of Chemistry (and therefore not in the Physics branch at all), papers tagged with Physical chemistry (or any of its children/subtopics) would not be found (or counted). 

Abuses 

The most common misuse of polyhierarchy is overuse: the tendency to give terms multiple parents without sufficient reason.  

While it is theoretically perfectly valid for a term to have two, three, or even more parents, in most taxonomies this will be rare. If you find yourself with many terms with lots of parents, take care to examine each with a critical eye. Often, weak polyhierarchical relationships are better suited as associatively related terms.  

That said, navigational taxonomies, used to structure pages on websites, and product taxonomies (often used for the same purpose) benefit from robust polyhierarchy. In such cases the primary purpose is to frictionlessly guide users to content or products, so standards compliance may take a back seat (especially if the taxonomy is not used for analytics). 

Reasons to Avoid Polyhierarchy 

While I generally advocate polyhierarchy, it can present some challenges; there are situations in which monohierarchy might be mandated and multiple parents disallowed completely. 

Structurally, a monohierarchy is a simple tree structure, while polyhierarchy is a directed acyclic graph. Any commercially available taxonomy software will maintain reciprocal relationships automatically, but managing polyhierarchy in spreadsheets (the most common application used outside of taxonomy software) is difficult. 

The many-to-one nature of polyhierarchical relationships, while conceptually intuitive, can present challenges for other systems consuming taxonomies (via API or import) from a dedicated vocabulary management system. If, say, you’re exporting a taxonomy to the SharePoint term store (this issue is discussed in a blogpost by Heather Hedden) your polyhierarchy will break on import. This same issue can occur whenever a consuming system is not equipped to deal with many-to-one relationships. 

Similarly, since polyhierarchy admits multiple broader terms, polyhierarchical taxonomies will feature more than one path to a term. The path (sometimes called full path) of any term is simply the chain of terms, starting with the top term, that leads through parent-child relationships to that term; this is just a different way of expressing its position in the hierarchy. For example, in this simple structure: 

Products 

-Sporting goods 

–Baseball equipment 

—Baseball bats 

—Baseball gloves 

—Baseball hats 

—Baseballs 

…the path to the term Baseball gloves can be expressed as: 

Products > Sporting goods > Baseball equipment > Baseball gloves 

(The delimiter > is arbitrary but not uncommon; / or | or any other delimiter will do.) 

In a polyhierarchical taxonomy, any term with multiple parents—as well as all of its children!—will have more than one path. Some consuming systems consider the full path of a term its unique identifier, so multiple paths to a single term are not possible. Suggesting a restructuring of the consuming system’s architecture to accommodate the polyhierarchy in your taxonomy may be met with skepticism. 

Polyhierarchy is a good argument for graph-based taxonomy management systems, as the nature of RDF graphs is suited to the many-to-one nature of polyhierarchical structures. 

Faking It 

If you find you need polyhierarchy but are prohibited, for any reason, from using it directly in your taxonomy, consider using a similarity relationship to equate terms 

Instead of giving a term multiple parents, use two different terms (these may or may not need to have unique term labels depending on your taxonomy system) and equate them to one another using a reciprocal relationship (one you’re not using for anything else). Many taxonomy systems allow you to create unique RT (Related Term) relationships, or perhaps to use common existing relationships designed for this purpose like SKOS:exactMatch or OWL:sameAs. This is, admittedly, a kludge, but it lets you declare an equivalence between terms without using a generic RT relationship (which you’re probably using for actual RTs). 

Such equivalence relationships may or may not be apparent to users, but they provide back-end logic for grabbing equivalent term pairs. It is of course possible to surface this to users as a kind of see also reference to guide them, depending on your application and use case. 

I consider polyhierarchy to be indispensable (when not misused and when no prohibitive external restrictions exist) for accurately using taxonomies to model conceptual relationships.