All technology-driven organizations benefit from advanced analytical techniques—they are perfect for tackling big-picture business problems. And while deploying a knowledge graph, which inherently helps analysts and knowledge workers by automatically organizing and connecting their data, there’s still a big step between graph data and actionable insights.

In most conversations about knowledge graphs, this jump between data and insights is where the conversation stops because they’re two separate but closely-connected processes. But as someone who is trying to scope and implement the right technology to help your analysts and knowledge workers be vastly more productive with the data you already have, you’re probably wondering a lot about that mysterious gap.

How does an organization transform the data and relationships stored within a knowledge graph into usable insights? And, perhaps more importantly, how does an organization do that while grasping the knowledge graph’s entire context and keeping up with the constant flow of new data?

That’s exactly where the engine kicks in. And while most conversations about knowledge graphs leave the engine behind because they’re not explicitly connected, we want to do our part to dispel the assumptions and mystery.

What is a knowledge graph’s engine?

An engine is a process or algorithm, sometimes utilizing AI technology like machine learning (ML) or natural language processing (NLP), which reasons over your knowledge graph, with the full context of the data and relationships, to produce insights or instructions that solve a specific business problem.

Engines operate outside of your knowledge graph, but heavily leverage the data it holds in the form of nodes and relationships. The engine begins by querying your graph data. In the case of GraphGrid, that often happens through Showmes, which allow developers to create dynamic APIs, using the Geequel graph query language, to return targeted sets of graph data. When GraphGrid updates the knowledge graph with an automated NLP ingest process, the Showmes also update their results.

Once the engine has the graph data, it can start to reason over, process, compute, and infer insights using whichever techniques your developers and engineers can dream up. It could be as simple as populating highly relevant dashboards for your knowledge workers to reference as they plan future initiatives or as complex as a suite of ML processes to make specific predictions about your industry’s trends given historical data.

An engine is inherently unique to your organization, so we can’t strictly define what kind of processing/computing/inferring it does. We can, however, talk about a few popular examples of models to help round out your view of the possibilities.

Engine examples from Google, Peloton, and beyond

When you Google “GraphGrid,” a simple query takes a pretty extraordinary journey in just a few hundred milliseconds. While Google Search’s exact data architecture isn’t fully known, we do know the company utilizes graph-based data to store and build those results.

But Google doesn’t give you raw graph data, letting you explore nodes and relationships directly, the way you might in the knowledge graph portions of a composable data platform like GraphGrid.

Instead, Google adds a layer between the graph data and the results pace, which is their engine: the infamous Google algorithm. Your simple query returns a bevy of graph data, and it’s the algorithm’s job to perform the extraordinarily complex transformation, based on everything Google knows about each page and you, to deliver you the results you’re looking for.

And only the most relevant ads.

Search engines are only one type of software that converts knowledge graph data into something more meaningful. Recommendation engines are another popular choice that you likely run into during your day-to-day life, like apps you use to receive customized workout and nutrition plans, or the way services like Netflix and Spotify continuously surface new content based on what you’ve watched/listened to most and enjoyed in the past.

Or, if you look back into GraphGrid’s own history, the advanced analytical problem that Peloton faced for understanding who their customers were on a deeper, more personal level to group them into ideal cohorts for retention. Peloton knew that if they could help like-minded people, sharing interests, music preferences, or favorite instructors, build community and want to succeed together, they could help more of them stick to their fitness goals. They needed an engine that could “perceive” all the nodes and relationships of their knowledge graph and solve that problem on a very tactical level: Output cohorts of Peloton users with the highest probability of getting fitter together.

We can’t say exactly how each engine works on a technical level, but they all exist to solve a specific problem for the organization using their knowledge graph as a foundation.

The path to your engine’s first output

You never start a project involving knowledge graphs with its engine. You don’t even start with designing, building, and deploying the knowledge graph and associated services (natural language processing [NLP], data stores, plain text search, change data capture[CDC]).

Instead, you start with the core business problem you’re trying to solve, either internally as a means of competitive differentiation, or on behalf of your customers. This might be delivering accurate and helpful search results, giving customers healthy dinner options, and driving carbon-friendly investments, if we’re to use the examples we’ve already mentioned.

Once your organization has identified this problem, agreed that solving it requires advanced analytics, and agreed that a knowledge graph provides meaningful advantages over other methods, like data warehouses and SQL queries, you can start to build your knowledge graph.

That means building a factual knowledge graph based on the problem you’ve defined. By thinking critically about the world around your organization, and applying that to how graphs work, you can start building a knowledge graph at the biggest scale and lowest resolution possible. Here are some pointers to keep in mind:

• Document how things are related to each other in the world around your organization. Are they connected through previous business dealing, product transactions, proximity, or similar characteristics? Add this context to your knowledge graph as metadata to open new avenues for queries and analysis.
• Identify process patterns in your industry/vertical.
• Begin with basic patterns and relationships based on what you can plainly see in the landscape that is your data, your organization, and the industry or vertical you work in.
• Aim for the simplest output or recommendation possible. Prioritize getting your knowledge graph and engine up and running as quickly as possible over having perfect results right away.
• Remember that knowledge graphs, and thus their engines, can and should be curated, expanded, maintained, and perfected over time. There’s no risk of inadvertently boxing your knowledge graph, and thus the results of your engine, into a box that’s harmful to how you use data in day-to-day decision-making.
• Avoid writing more code to solve your business problems.

From there, you’re off to building your engine—working with an expert or tinkering yourself until it produces the kind of meaningful results your organization needs to solve problems for itself or its customers. That means breaking down more data silos, writing better queries, and discovering new ways to build relationships between the data you already have.

What benefits do you get from engines built on knowledge graphs?

As you build and iterate on your engine, you’ll start to unlock benefits in addition to solving the immediate business problem:

• Your data analysts and knowledge workers can spend more of their time crafting insights over writing complex graph data queries or trying to build hard-coded logic themselves using traditional programming methods, like booleans, string manipulations, and regex.
• They also operate under lessened stress of feeling like they have to understand every aspect of your organization’s data landscape, as the engine operates with the full context already.
• Because engines aren’t defined by rigid logic, they can produce dynamic and relevant outputs that aren’t confined to what your organization already knows to search for—and their output is also more easily consumed by other systems.
• Organizations can transition from developing logic to developing knowledge, an essential step for building the feedback loops that continuously improve your knowledge graph and help analysts make better decisions.
• A good engine solves layered, conceptual problems, like helping a building owner reach their carbon goals by recommending a specific 20 to 30-year investment plan based on the cost and effectiveness of each upgrade, which can open up entirely new areas of research for your organization.

But, as we’ll talk about in an upcoming blog, the process of iterating on an engine can send you down some rocky roads if you focus too heavily on optimizing the engine over improving the quality and breadth of your underlying knowledge graph.

A simpler path to knowledge with GraphGrid

For the fastest path to building a knowledge graph and engine, there’s GraphGrid, a composable platform that combines graph and artificial intelligence to help teams accelerate the development of graph and AI solutions. These solutions delivered in weeks help teams control, manage, and collaborate across their knowledge graph more effectively.

GraphGrid doesn’t supply the engine, but it gives you every resource you need, like graph databases, NLP ingestion services, and data integrations, to help you initiate that engine and create valuable feedback loops to improve the quality of the knowledge your graph holds continuously.

Download GraphGrid for free, start ingesting your organization’s unstructured data, build your network of relationships, and start crafting the engine that enhances the insights and decision-making capabilities of your people.

Once you’re there, you have the engine—both technological and cultural—to eliminate data silos while solving challenging business problems for long-term value.