We get asked this question a lot-what is the difference between taxonomy and ontology? In this post we will share some examples that will help make a complicated topic a little more approachable.
What is taxonomy?
Let’s start with taxonomy.
Taxonomy identifies hierarchical relationships within a category.
Taxonomies are useful for organizing information for both internal and external consumption. Within a company, they can be used for classifying documents into categories such as proposals, contracts, letters, and briefings.
Another example is your own folder system of documents, where you might organize them by topical category, client, or type of document such as proposal or report. You might also just file them by year.
Each taxonomy is designed to categorize items within just one dimension.
For example, home improvement stores have taxonomies of their products.
Tools are classified into power tools and hand tools,
and hand tools classified into products like hammers and wrenches,
and then further broken down into different brands and sizes of wrenches.
Finally there would be one specific product, referred to as an “entity,” at the lowest level.
The categories enable the user to navigate to the desired product.
However, taxonomies have limitations. They cannot represent relationships across different domains; they can only define categories within a domain.
How are ontologies different?
But what if you want to connect certain specialty items into a list of potential clients in those areas? A taxonomy for tool types cannot do that on its own, but when connected with other taxonomies for “compatible materials” and “client needs” into a larger structure of an ontology, it becomes possible.
Ontologies achieve a higher level of sophistication by providing richer information, including information about the relationships among entities.
In the world of product information management (PIM) systems, we see relationships such as accessories in taxonomy, but there is not a way to further that relationship or extend it to other matters such as whether customers like the product. It’s either linked or it is not.
Ontologies take taxonomy a step further, by providing added layers to that relationship that and take it outside of just the product domain to other domains such as customer data and digital assets.
That’s still a little esoteric so let’s go back to the home improvement example from the discussion of taxonomy.
In addition to a taxonomy of products, the store might have other taxonomies, such as categories of customers.
This could include customers who are consumers and contractors,
and sub-categories within those, such as contractors who are roofers and electricians.
By relating categories of users with products sold in stores, an ontology would present a list of products relevant to those users.
Another taxonomy could describe different types of projects, such as installing flooring or replacing a toilet.
If a website asked a user the question, “What do you want to do?” and the user selected the option of “Replace a toilet,” an ontology could allow the presentation not only of the different brands and types of toilets, but also a list of accessories and tools needed to do the job.
If the answer is “Build a deck,” then the store could present a suggested list that included supporting posts, decking lumber, deck screws, and a circular saw. Otherwise, the search engine will not be able to respond with the properly related elements. Ontologies achieve a higher level of sophistication by providing richer information, including information about the relationships among entities.
Ontologies allow multidimensional relationships to be defined.
In order to do this, however, the ontology needs to be built out to cover all these relationships. If the ontology is only partly completed, the results presented to the user will be inconsistent or incorrect.
Developers should not underestimate the commitment of time and resources that is required to analyze and document all the potential connections across domains enterprise-wide.
An interesting feature of ontologies is that the relationships depend on context. Whereas a taxonomy is defined and static, the connections revealed by ontologies are dynamic. For example, if an element such as season of the year is selected, some of the product offerings could change, while others might not. A relationship may be made active in one situation and inactive in another. One selection can trigger others.
A Star Wars example of an ontology
If the concept is still murky, consider this example, where I’ve used an ontology tool called OWL to illustrate an ontology of Star Wars information. (See the diagram below.) A set of relationships that shows the need for relationship metadata is with Han Solo, Leia Organa Solo, and their children. For example, Leia is the mother to Ben Solo (aka Kylo Ren) in the movies and she is also mother to Jacen, Jaina and Anakin Solo in the book series.
The Parent Child relationship is an inverse relationship that can have the additional metadata for Mother as the Parent for Leia and Jaina. Further metadata can be added to indicate that the relationship is in the book series but not in the movies. Additional information as to where and when the child was born can be added as well.
Relationships can be created for different kinds of objects. Leia, a character in the movie, lived on the planet Alderaan, which is another entity; Alderaan is in the category of “planet.”. Metadata for the relationship between Leia and Alderaan, such as the timespan when she lived there, can be added. Leia was portrayed by the actress Carrie Fisher, another relationship (the character-actor relationship) but in a separate dimension of the ontology. We can see different taxonomy focal points for characters, actors, and locations being used within this ontology, among many others, to create many different kinds of relationships and the relationship metadata.
Underlying characteristics of ontologies
Ontologies are a key ingredient for personalization and proactive marketing, as well as for customer support. But they are not easy to develop, because their construction requires a holistic understanding of the language of the business and the customer. The underlying relationships must be designed into every activity and function in the company, including processes, applications, navigational structures, content, data models, and the relationships among concepts. They contain all kinds of language variations, alternative spellings, translations, acronyms, and technical terms. They can describe what a document is (e.g., a contract) and what it is about (e.g., a service agreement or a specific vendor).
Although ontologies are more sophisticated than taxonomies, it is important to remember that they also depend on taxonomies. Each aspect of the relationships needs to be broken down into well-designed and complete structured taxonomies that can be related in the first place.
However, merely creating a set of taxonomies does not mean an ontology has been created.
The interrelationships among the entities in the taxonomy are the essence of the ontology. Therefore the ontology reflects both a broad view of the enterprise and a very detailed description of its components.
Benefits of ontologies for intelligent virtual assistants and bots
Another motivation for the use is that ontologies can also support advanced capabilities to drive intelligent virtual assistants and bots. They can form the basis for inference engines—mechanisms to answer questions that have not been pre-programmed into the bot.
Bots powered by ontologies are more effective because they have an understanding of the organization and how all the element relate to each other.
In addition, they are faster to deploy, more scalable, and more cost-effective. Every aspect of business requires contextualized knowledge. The role of AI in an intelligent virtual assistant is to use the ontology to assist with this contextualization, which significantly advances the usefulness of the existing content. The bots will function more effectively and seem more natural because they have access to a more sophisticated set of underlying information.
An important characteristic of successful bots is their ability to detect intent, an ability that is fostered by being ontology-based.
For example, if a customer is not able to connect a printer to the network, the troubleshooting bot can determine the customer’s intent by first extracting the elements of the problem from the customer statement (the “utterance”).
“I cannot connect my printer to the network” contains the entity “printer” and “network” and the symptom “cannot connect.”
Chatbots and personalization engines infer intent in part from certain words and phrases. These elements are captured in the ontology along with synonyms and variations such as “unable to connect” or “not connecting.” Because the ontology allows for more than just a keyword search, it is more likely to capture intent no matter how it is phrased.
The intent, which the bot determines from this information, is “fix printer connection problem.” Having determined the intent, the bot can walk the user through steps to solve the problem.
Why information architecture is important to ontology success
In order to function at an optimal level, taxonomies and ontologies both require a solid information architecture (IA), which addresses how to organize and structure enterprise content.
IA is particularly important when it comes to developing effective artificial intelligence (AI) solutions.
Seth Earley, the CEO of EIS, often says “There is no AI without IA.” Trying to develop sophisticated applications without a well thought out IA is like trying to build a skyscraper without the steel beams. It might hold up for a while, but under any kind of stress, it will collapse. One of the virtues of good design is that it allows for flexibility and growth in the future, a requirement for companies that want to compete.
Taxonomies are often the first building block in an information architecture. They provide the first “sorting” of the content in an organization and undoubtedly can move your content from a state of chaos to a more ordered state.
To advance to a higher level of sophistication, though, your organization will need to develop an ontology. This does not need to be done enterprise-wide all at once; it can be done in stages, starting with one function such as marketing or customer support.
However, the initiative should be carried out with a long-term roadmap in mind that sets up a framework for future steps. To get the full benefits of ontology, it should be implemented enterprise-wide.
To get your company started on a roadmap for powering your business with more effective information architecture and begin work on an ontology that captures the essence of your business, give us a shout.