Happy Halloween! If I had to pick a word relating to my work that incites the most heated debates about its meaning and purpose, I would have to go with ontology. Let’s be honest, it sounds like a term that should only be used in an academic setting, or by someone trying to appear smart. Ontologies often get confused with taxonomies, and the distinction between ontologies and knowledge graphs can be unclear; clients usually ask why they even need one, as the introduction of an ontology is a new concept for the business.

It’s a haunted time of year, so let’s make this scary word a little more approachable. In this blog, I want to help alleviate concerns about ontologies by defining what the word means for an organization so that you can discuss them with your colleagues without inducing fear.

How EK defines Ontology

Enterprise Knowledge (EK) defines an ontology as “a defined model that organizes structured and unstructured information through entities, their properties, and the way they relate to one another.”

Let’s tackle each part of that definition separately.

A Defined Model

The simplest way to think about an ontology is as a data model. I commonly use “data models” as an alternative to ontologies – this similarity is best realized by looking at its Wikipedia definition:

A data model is an abstract model that organizes elements of data and
standardizes how they relate to one another and to the properties of real-world entities. 

Ontologies and data models both provide detailed and visual representations of information, helping us understand what we have and what we can do with it. Both can be designed in Excel or through model-specific languages such as UML (Unified Modeling Language) or OWL (Web Ontology Language). However, ontologies slightly differ from data models in that they focus on describing an entire data domain, such as sustainability or finance. Also, ontologies define the meaning of a domain by providing structure and definitions, whereas data models are normally only the structure. EK experts have defined several steps and best practices to help you build a successful model.

Organizes Structured and Unstructured Information

Every organization has a wealth of potential data waiting to be leveraged. Deliverables (documents), shared documentation sites (like Confluence and SharePoint), and structured data sources (HR or project data, databases, etc.) are all relevant inputs to help an organization answer questions. In our model, we want to bring this data together and describe it well enough that all our users can understand and leverage it. Ontologies excel in data aggregation situations, as their purpose is to represent a concept of information, regardless of the shape the data takes (structured or unstructured).

Through Entities, Their Properties, and How They Relate

When we describe the data that we have, we organize it into groups. For example, at EK, we could create groups for employees, clients, projects, and deliverables. Each one of the groups is a type of entity, and each individual in the group is an entity. That is, all of my colleagues would be entities, and so are the projects we have worked on. Every entity we examine has some information associated with it, like a name, description, or date: these are the properties. And, at EK, we know that employees work on projects for clients. This association is an example of how our entities relate.

Ontology Use Cases

Unified Views of Knowledge

Developing an ontology, or data model, is an important part of understanding what an organization has, how it can be brought together, and how it can be leveraged to support a successfully unified user experience. Often described as 360 Views or Knowledge Portals, a unified view of an organization’s knowledge enables internal and external users to find and discover information from multiple sources in one place.

From an internal user perspective, knowing who is an expert in a particular topic or who has worked with which clients on which projects – and being able to find all of that information in one place – enables employees to make decisions and take action faster. This information is usually scattered across multiple systems, but an ontology provides evidence of how an organization understands data across systems, allowing architects and designers to approach a solution with an organization-wide mindset.

From an external perspective, being able to find all product documentation, support cases, and FAQs in one place alleviates customer frustration when looking for answers. In this case, the ontology enables an organization to identify and prioritize knowledge that should be made readily available to users.

Powering Recommendation Logic

One of my colleagues recently published “5 Steps For Building Your Enterprise Semantic Recommendation Engine,” and, lo and behold, step two is “Create Supporting Data Models”. To support a comprehensive recommendation engine, an organization should create ontologies to define the web of complex relationships within data. These relationships between people, clients, projects, and so on help to realize the recommendation results, as a developer can leverage those relationships to create paths from some input to the desired output.

For example, EK worked on a course recommendation system for a healthcare provider. The recommendation engine leveraged the relationships between key learning competencies and courses to help personalize course recommendations for individuals based on their learning goals. Additionally, the ontology helped highlight areas where the organization could add information and improve data quality to provide more recommendation pathways to consider.

Conclusion