One of the challenges in creating hierarchical taxonomies is that there can be multiple ways to categorize concepts and thus design hierarchies. There are multiple methods to deal with this, including polyhierarchy and facets. Now that taxonomies are more often extended with ontologies, attributes can also be used for additional “classifications” of things.
Dealing with multiple hierarchies
The traditional method of dealing with multiple methods of categorizing concepts has been to
put the concepts into a “polyhierarchy,”
which means the concept has more than one broader concept, and thus belongs to
more than one hierarchy. The occasional polyhierarchy
is acceptable, but if a polyhierarchy becomes extensive (numerous concepts
belong to the same two hierarchies) due to different methods of classification,
this does not serve the purpose of helping users find the concepts and tagged
content desired. When everything is in a polyhierarchy, the guiding purpose of
a hierarchy gets lost.
When the issue is multiple classifications for things, then what is known “faceted classification” is often the answer. A faceted taxonomy design involves designating a facet for each method of classifying things by. For example, products may have facets for brand name, product type, functional use/application, industry market, user type, etc. Each of these could be a facet for products.
Sometimes, however, there may seem to be more possible ways of organizing or classifying something than are practical for facets. It could be within a facet. For example, if you have a facet for product type, you could further classify the product types by product family, by generic product type (narrower “is a” sub-type of the broader), by broader system of which they are a component (narrower is a part of the broader), by size, or by a certain key feature or characteristic.
Recently on a project, a client suggested an added level of hierarchy within the facet for named product models for a classifying feature that impacted the product size. The problem was that this would combine named entities (proper nouns) of product models and generic types within the same facet. This combination should be avoided in facet design, because facets enable users to search and filter by different methods, such as either by name or by type, and there are scenarios when users would choose one over the other. Combining types and named entities in the same facet can cause confusion. This is where an ontology model may be the solution.
Ontologies for further classification
Ontologies enable customized relationships between classes (which tend to be the same type of high-level grouping as a facet) and customized attributes for members of classes. When we think of ontologies, we usually think of the custom relationships, but custom attributes can support what could be considered “types.” These “types” might have been extra hierarchies, and thus attributes provide a solution to the multiple classification problem.
If multiple methods of hierarchical classification seem to be overlapping, you should consider making one or more attributes instead. In my recent consulting case example, what the client originally proposed as top concepts for grouping product models (as a classifying feature impacting the product size), we decided would work better as an attribute of the product models. So, the facet would contain only named entity product models, and the hierarchy would be by model family only.
When an ontology is defined as a formal naming and definition of the types, properties and interrelationships of entities in a particular domain, we might think we have to define everything in the domain, and thus creating an ontology is a large, complex project. Often, what we need is only “some” ontology. While using the features, rules, and data model of an ontology, we need to define only the types, properties, and interrelationships that need to be defined for a business purpose. This could be defining just a few custom attributes (properties) without even adding any custom relationships.
More information about attributes in is my prior blog post. "Taxonomies and Attribute Data."
Examples
In the prior example, the product model feature had originally been proposed for the hierarchy for the purpose of “grouping,” because users might want to look up the product models by that feature. If implemented in a knowledge graph, the attributes, managed in an ontology, will also support users looking up entities by their attributes. So, the hierarchical design is not necessary.
Any “groupings” of named entities (by region, size, role, etc.), should be reconsidered as attributes of the named entities. Other examples are groupings of vehicles by engine type, which could have engine type as an attribute instead, or groupings of appliances by energy type, which could have the fuel type as an attribute instead. So, instead of Electric cars narrower to both Cars and Electric vehicles, Electric, Internal combustion, and Hybrid would be attributes for Cars.
Conclusions
Shared data model standards based on RDF (Resource Description Framework) and the use of dedicated taxonomy/ontology management software that combines taxonomies with ontologies make this solution of using ontology features to resolve multiple hierarchies easy to attain. Instead of thinking that we could extend a taxonomy into an ontology in the future, we should be thinking of how to design a knowledge model now that best serves the body of knowledge and the users.
