Knowledge Graphs – Part II: What Are They Good For?
Read - Part I: What is a Knowledge Graph?
I’m an amateur woodworker and, living in a heavily forested area, every so often I’ll see a gorgeous piece of live-edge wood for sale on the side of the road. Each time it takes every ounce of my willpower to keep myself from pulling over and purchasing it. However beautiful the wood may be, I know unless I have a particular project in mind, it will just hang around my house taking up space. Technology is the same way. There’s no point in having it just for the sake of having it, you have to put it to work.
In the first installment of this blog series, I introduce the concept of a knowledge graph. But as nifty as they are, to be useful, a knowledge graph needs a domain—it has to be a graph about something. It could store knowledge about people, organizations, content, machines, even the very data landscape of which the knowledge graph is a part. This article will explore some of these key applications to demonstrate the ways you can put a knowledge graph to work.
Graphs about People
People are one of the most common subjects for knowledge graphs. After all, people and their actions generate much of the data companies use to run their businesses. A knowledge graph allows organizations to link all of the data about a person together and then connect multiple people together into a network.
Customer Graphs. Businesses cannot exist without customers, which makes understanding them vital to the success of any enterprise. It shouldn’t come as a surprise, then, that companies often start their journey into knowledge graphs by trying to map information about their customers.
Consider the challenge of a customer 360 strategy. In order to create a unified view of every customer, the department has to create a unique customer entity and connect it to data drawn from a multitude of business systems. Knowledge graphs provide an intuitive way to link this kind of information. A knowledge graph allows companies to turn each customer into a node in the graph that’s connected by relationships to the data about them. Within the graph, not only is the data unified, but it’s also connected to its meaning. The relationships themselves express how the person relates to the data. (See figure 1.)
Figure 1. A Sample Customer in a Knowledge Graph
A knowledge graph like this one can link master data such as name, age, and address to a person just as easily as their transaction history. And what’s more, because each node is unique, it can link customers to each other in ways that might not be captured by source systems. In the graph above, perhaps a Customer B also lives at 546 Drury Lane in Boston. Now we know Customer A and B live together even though that specific fact was never recorded.
The deeper understanding provided by a customer knowledge graph also facilitates better customer recommendations. Because knowledge graphs provide their data in a machine-readable format, data scientists can train machine learning (ML) models on them. These models pick up on the relationships between customers to judge their similarity and use that to suggest products with greater accuracy.
Customer knowledge graphs also have application in the realm of fraud detection. By analyzing the relationships between groups of customers, their IP address, transactions, known credit cards, etc., fraud specialists and security algorithms can readily identify suspicious behavior that might be invisible in traditional systems. Perhaps a customer’s most recent transaction occurred in a new store. In and of itself this may not be unusual, but if the signature looks different than previous ones—the location of the store is across the globe from the customer’s address, and the products purchased are typically bought by customers of an entirely different demographic—something might be up. Because the knowledge graph both stores and connects this information, conclusions become easier to draw.
Employee Graphs. Companies also create person-focused graphs of their employees. As with customer graphs, employee graphs are a way to unify the data about the people critical to an enterprise’s success. These knowledge graphs can serve as an org chart on steroids. Not only do they provide information about the company hierarchy and unify human resource data, but they can also help link employees through the projects on which they work, creating a social and productivity map of the entire company. This map can then be used to evaluate performance, improve company culture, and monitor interactions.
Graphs about organizations
Knowledge graphs can take more than just people as their subjects. Companies frequently create them about other organizations. A robust knowledge graph can serve as a kind of super customer relationship management (CRM) platform. It might model data extracted from a traditional CRM or it might serve as the initial system of record. In either case, it takes the data to the next level by linking it to other data to create context. An organization becomes a single node in the graph linked to other nodes that might consist of contacts, contracts, projects, meetings, emails, or any number of other relevant entities. Once again, the graph structure allows new information to emerge that wouldn’t be captured in a table. A company would be able to track its relationship with a particular contact across multiple organizations and see how sales to that contact change over time, because the contact would remain a unique entity linked to an employer by a relationship rather than an attribute.
A robust knowledge graph can serve as a kind of super customer relationship management (CRM) platform.
Company intelligence is another key use case for a knowledge graph of organizations. Financial firms looking for investments, or companies in any vertical trying to track competitors or potential acquisitions can benefit from this type of graph. Like a person-focused graph it facilitates the modelling of social networks, only of companies instead of people. Links in the graph can reflect complex business relationships that help new insights and connections to emerge.
Graphs about content
Knowledge graphs don’t have to store information about external entities, however. They can also facilitate better understanding and use of assets created within a company. Content management is one of the most important use cases for knowledge graphs today. In fact, much of the academic underpinning of knowledge graphs comes from the library science discipline which takes content management as its central calling.
Content management is one of the most important use cases for knowledge graphs.
In a content graph, raw content is stored as a node and metadata about the content is linked to it. This metadata can help create associations between pieces of content improving content search functions, much as customer graphs can improve recommendation systems. The knowledge graph can also store information about how to present the content on different platforms or in different geographic regions. For example, the text of an article might be linked to code that tells the website how to display the text on a phone versus a desktop. It might also link to regional versions of the content, allowing these variations to still be identified with the original piece.
Graph about machines
The assets stored in a knowledge graph don’t have to be entirely digital either. Particularly in the manufacturing industry, companies create knowledge graphs of their production lines. In this case, the knowledge graph contains nodes representing each part of the machines in use. These nodes connect to the internet of things (IoT) data generated by the sensors on the machines and linked together to form a virtual copy, or digital twin, of the factory floor. Using this virtual model, companies can test new processes, or diagnose problems by running analytics on the graph.
Graphs about data
Finally, organizations can apply knowledge graphs to the enterprise data landscape itself. On a basic level, this might take the form of a knowledge graph-powered data catalog. In fact, many leading catalogs use a hidden knowledge graph as their engine. A data catalog as a graph makes sense because, at its core, a catalog simply links together metadata describing a particular data asset, such as descriptions, locations, statistical information, reviews, access rights, and lineage. This use case is very similar to the content management use case, but the content in question is actually data.
The holy grail for data-focused knowledge graphs, however, is the enterprise data fabric. The data fabric goes one step beyond the data catalog to link information about how to access each data asset into the graph itself. In the case of a data fabric, the knowledge graph acts as a kind of data virtualization engine to unify the entire data landscape. Consider a node in the graph that represents a particular table. In addition to information describing the table, the knowledge graph also contains the code to automatically query the source system, retrieve, and format the table. This allows for federated queries that reach through the knowledge graph to access every other data source or business system. A data fabric does more than virtualize the data, though. Because it relies on a knowledge graph, it uses relationships to record how each system understands the data, while allowing the data itself to exist outside out of an application silo.
The holy grail for data-focused knowledge graphs, however, is the enterprise data fabric.
Is my use case a good fit for a knowledge graph?
While the examples covered in this article are by no means exhaustive, hopefully, they give you a better sense of what’s possible with a knowledge graph. To evaluate other potential applications, ask yourself the following questions:
Do the entities I want to know about naturally form networks, i.e., is the data graph-y?
Does this use case require linking metadata or additional context to the data itself?
Are there insights in my data that will only emerge if it's interlinked?
Are the relationships between the data just as important as the data itself?
If you answered yes to any of these questions, it might be worth looking into implementing a knowledge graph. Fortunately for you, in the next article in this series, we will look into the logistics of building a knowledge graph at an organizational level.