The Value of a Knowledge Graph: Four Business Perspectives

Often the terminology of the knowledge graph world overwhelms those just beginning to learn about it. There are slews of acronyms like RDF, OWL, SHACL, and IRI, not to mention words like “ontology” and “semantics” that seem to have waltzed out of a philosophy student’s nightmares. But at the end of the day, knowledge graphs are actually very intuitive, because they approach data the same way humans do – as webs of related concepts.

In this post, I will cut through the jargon by focusing on how knowledge graphs deliver business value for four key personas.

Core Features

To begin, let’s talk about the three core features that give knowledge graphs their capabilities:

Unique Identities

Every concept in a knowledge graph, whether a person, place, transaction, document, or something else entirely has a unique identifier. That means we can use any number of different terms to refer to the same conceptual object.

As an example, if I add a new employee to a graph of personnel in my organization, I’m adding them as the concept of a person, not just a name. That person object will likely have names associated with it, but it’s the concept of a specific and unique individual. So if that person’s name changes, or they start going by a nickname, I don’t edit the record of the person, I simply associate new names with them. In effect, a knowledge graph works with “things” not “strings.”

Highly Defined Meanings 

Once I have unique concepts in a graph, I have to define them. It’s all well and good to say that I’ve added the concept of a person to a knowledge graph, but a machine does not inherently know what a person is. I have to teach it by defining a “person” using machine intelligible standards.

For instance, I might say that a person has a name, a birthday, and a gender. So now every person in my graph should be connected to other objects that are name, birthday, and gender objects. I might further define a sub-category of person that’s an employee. Those people must also have salaries, start dates, roles, and so on.

Embedded Logic

The definitions described above extend beyond attributes to codify business logic as well. I might define a city as having to belong to a state and a state as having to belong to a country. As a human, I know that a city within a state must be within the same country as the state it belongs to, but traditional approaches to storing information can’t make that leap.

In a knowledge graph, our clear and detailed definitions of concepts allow the graph to make those kinds of inferences. I can also embed other types of business rules as well. For instance, I might define a person as having an age of less than 200 because no human being is that old.

The combination of these three attributes allows the knowledge graph to generate value for several different players.

The Analyst

The most obvious way knowledge graphs prove their value is through analysis. Analysts need the capability to discover and identify assets, make predictions, and answer both quantitative and qualitative questions. Knowledge graphs with their clearly defined objects and definitions make these tasks easier.

Consider the business question “How many of our customers live in New England?” Using traditional methods, that question becomes a complex query. First, the analyst needs a table with all of the customers across all of the lines of business. Next, they have to find a way to link them to a location and abstract to the regional level which likely involves multiple joins and manual aggregation. They need to associate them with a region, but what is New England? Do they include Connecticut? Different folks might have different definitions.

With a knowledge graph, it’s easy. First, the graph already contains all of the customer objects because it doesn’t silo data into tables; it just associates them with different lines of business. Then, based on the definition of a customer, each customer is already associated with a location, which the graph, through embedded logic, understands as belonging to a state.

Ideally, the company has previously defined the region of New England and the analyst can just ask the question as stated. But if New England doesn’t already exist as a concept within the graph, the analyst simply creates a new region concept and associates it with the concepts of the appropriate states. There’s no need to edit thousands of rows, because the concept of a state is already linked to the concept of each customer, so inference allows them to be associated with a region.

The ease of these queries enables the analyst to better identify risks. If there’s a backlog at the port of Boston and the company anticipates shipping delays, it can get in front of the issue by pulling all of the information on in-process orders to customers in New England – even though there’s no mention of “New England” on any of its invoices.

The Chief Information Officer

The next area where knowledge graphs prove their value is oversight and control. CIOs use dashboards and need to be able to drill down to understand the infrastructure of their organizations. They most identify where bottlenecks will appear and where their budget is going. They need to ensure regulatory compliance and conduct more abstract, strategic analysis.

The holistic approach taken by knowledge graphs enables sweeping views of the organization. Data is not arbitrarily broken up into siloed tables where the same concepts are repeated over and over. Each concept exists exactly once in the graph and is associated through rigorously defined relationships to others.

This makes pulling information from across lines of business relatively simple. A system used by  two different parts of the business is understood as a single platform because of the concept of entity uniqueness. The CIO doesn’t have to worry about double counting it because it appears in multiple places.

At the same time, knowledge graphs help enable regulatory compliance. Because different jurisdictions use different definitions of concepts, organizing data for reports can be a hassle. But in a knowledge graph, businesses can embed the definitions and logic that go with each regulatory body. Then reports for each agency can pull data from the unique core concepts using the appropriate definitions without any additional manual work.

The Operations Engineer

At a lower level than the CIO are the folks responsible for capacity. Operations engineers have to keep the lights on and IT systems running. They value the ability to make incremental improvements and prize automation. Unification and standardization are key aspects of their efforts to optimize systems.

This persona values knowledge graphs for their centralization and enforcement of shared definitions. In the example from before, the organization now has a standard view of “New England” because the definition is documented and built into our knowledge graph. Whenever any other questions reference New England, they will leverage the same definition, creating consistency throughout the business, and reducing future IT workloads.

The Chief Financial Officer

Finally, knowledge graphs deliver value to people like CFOs that worry about the bottom line. The reusability of knowledge graphs helps cut costs. Once a business defines a concept, it stays in the graph, so the graph only grows over time, becoming more comprehensive and useful. The first time I add a new concept to the graph I have to go through the definition process. After that, I get it for free.

To stick with my example of “New England,” once I’ve defined it and related it to other concepts, I can connect any information I add about New England to every other concept it touches without any additional work. Let’s say my business becomes multinational. I don’t have to update every customer record with a country. I just have to define the region of New England as being in the United States and then every customer in New England will show up in queries for the US.

At the same time, improved analysis opens up fresh opportunities, creating the potential for net new revenue streams. The same data now provides more value than before because it can fuel new products and services.

Conclusion

Hopefully, this post has given you a sense of how the core attributes of a knowledge graph – uniqueness, clear definitions, and embedded logic – enable businesses to generate greater value from the same data. Just by reusing previous work and creating firm definitions of concepts and the relationships between them, a knowledge graph makes it easier to answer questions, keep an eye on the business as a whole, and reduce costs. It may just be a matter of structure, but those slight differences can make a big impact.

Want to generate greater value from your enterprise data?