Taxonomies and Hierarchies

Businesses typically sell many different types of items and they need a way to organize their product records so they can identify, store, and find them. They do that through the use of taxonomies and hierarchies.

If a business sells party goods, they may sell balloons, tableware, and decorations. When they think about their products, they probably think in terms of those categories: all the different types of balloons are in the balloon category; all the silverware, tablecloths and paper plates are in the tableware category; and all the streamers, banners and posters are in the decoration category. Inside those categories, all the items have a similarity. There may be a lot of balloons in different shapes, sizes and colors, but they are all balloons. The business may then divide their products into more subcategories, such as dividing the balloons by the material they are made of: mylar and latex. They can keep dividing their categories until they reach a point that represents how they think of their products.

This type of categorization of data into categories and subcategories is called a treestructure. Think of starting at the root (or trunk) of the tree – that’s the main category: Party Goods. From the root, the data branches into subcategories: Balloons, Tableware, and Decorations. Then Balloons splits into subcategories: Mylar and Latex. The point where a category splits is called a node and so are the final subcategories (the ends of the branches). The actual products themselves (the item records) are assigned to nodes. Every record is assigned to one, and only one, node. Nodes can have multiple records assigned to them.

A taxonomy describes the path from the root to the node a product record is attached to. Every product record has a taxonomy. Taxonomies are typically written as: root.node.node…last_node (though they can be written in other formats, depending on the configuration of EnterWorks). For example: Party Goods.Balloons.Mylar is the taxonomy for the product record [balloon, #37, 10", red, birthday]. For example:

Each product repository has one classification system that defines the repository’s taxonomy. Each record appears only once in the taxonomy.

A hierarchy is similar to a taxonomy. Both are tree-like structures; however, a hierarchy interacts with product records differently. A hierarchy captures a path that someone might follow to find a product record.

Some items might logically be thought of as belonging in more than one category, so they can appear in multiple places in a hierarchy. Returning to our party goods example, if a customer wanted to buy paper plates for a birthday party, they might look in tableware, but they also might look in decorations. Paper plates with birthday party designs could be thought of both as tableware and as decorations. So a product item might be assigned to two different nodes and have two different hierarchies. A package of 10", purple paper plates might have the hierarchies: Party Goods.Tableware.Paper Plates and Party Goods.Decorations.Paper Plates.

A repository may have more than one hierarchy classification system. For instance, one hierarchy might be used to prepare the Spring 2021 Catalog and another used for the Fall 2021 Catalog. Some items might appear in both hierarchies, while others may only appear in one.

A simple way to remember the difference between a repository’s taxonomy and its hierarchies is: "A taxonomy is what the product is. A hierarchy is where someone might look for the product."