What Makes a Knowledge Graph Different from the Systems We Already Have?

ReadStats & TrendsCool AnimationsBest Practices
Written by Jeff Winter

I believe I first heard about knowledge graphs in 2023 or 2024, and the basic concept made sense to me almost immediately. A machine is connected to a production run, that run produces a material lot, and the lot is connected to a customer order. If something goes wrong, you follow those relationships to understand what might be affected. With my background in industrial automation and manufacturing software, I could see why that would be useful without needing much convincing.

What I couldn't have explained was how any of it actually worked. I don't come from a computer science or IT background, and although my work has given me a lot of exposure to industrial technology, there were parts of the underlying architecture I had never needed to understand in much detail. I could appreciate the example while still missing what made a knowledge graph different from the ways companies were already connecting information.

That bothered me a little. Weren't databases already storing relationships? Wasn't connecting production to orders something manufacturing systems had been doing for years? I wanted to understand what was different before deciding how excited I should be about it, which meant learning about knowledge graphs and spending more time with some much older ideas along the way.

The more I read, the more interesting it became. I also started to appreciate why something so straightforward to explain could be quite difficult to build. Understanding the diagram was the beginning; understanding what it would take to trust the diagram in an actual business was where I had more work to do.

The history of knowledge graphs

Knowledge graphs have roots in early work on semantic networks, including M. Ross Quillian's research in the 1960s. Researchers were already exploring how concepts and their relationships could help computers represent knowledge. I had associated the term with recent conversations about AI, so finding that history changed how I thought about it. The web gave those ideas a much larger setting. W3C published its first RDF recommendation in 1999, followed by revised RDF specifications and OWL recommendations in 2004. DBpedia began in 2007, extracting structured information from Wikipedia; Google introduced its Knowledge Graph and Wikidata launched in 2012. These were different efforts, but each helped make connected information more usable by software.

By the time I encountered the term, there was a substantial history behind it. Today's interest in AI adds another reason to care, because answering a question about a particular operation requires context about how that operation fits together.

My first question turned out to be reasonable: companies already connect information. Relational databases use keys and joins to bring related records together. Manufacturing execution systems connect production activity to materials and orders, while ERP, maintenance, and quality systems maintain other parts of the picture. Warehouses, lakehouses, integrations, and reporting models help combine that information, sometimes very effectively. Learning more about this made me more careful with the idea that knowledge graphs somehow introduce relationships into a world that previously had none. Master data management and semantic models can also establish consistent identities and definitions. A graph has to earn its place alongside those capabilities.

What helped me understand the opportunity was thinking about how often the same connections have to be reconstructed. Someone investigating a quality issue reconciles equipment and lot identifiers; another team builds similar logic into a report; an AI project later needs those relationships again. The information may be available, while the understanding of how it fits together remains scattered across applications, queries, and people.

A knowledge graph can represent entities, their attributes, and explicitly defined relationships in a form that applications can reuse. “Used in,” “produced,” and “allocated to” become connections that software can follow with agreed meanings. That is particularly interesting when answering a question involves several kinds of relationships across changing information. I began to see the potential in making that understanding reusable, although I wouldn't assume a graph is automatically faster or more accurate. For a stable report from a well-managed database, an ordinary query may already be the right answer. I kept coming back to a more useful question: where are people repeatedly doing the work of figuring out how things connect?

Defining the use case and shared data model

I found it easier to think through the decisions by staying with one question: which customer orders could be affected by a particular material lot? That gives the project a purpose and identifies the people who need the answer. I would want to understand how they investigate it today, how long it takes, and where mistakes occur before deciding what improvement is worth building. From there, the model needs the relevant materials, production runs, output lots, and orders, with clear definitions for their relationships. “Allocated to” and “shipped against” describe different situations, even if both look like a line between a lot and an order. An ontology helps describe those shared concepts and meanings. It can begin with the scope needed for this question and reuse suitable industry models as it grows.

Then I started thinking about the names. If maintenance calls a machine “CNC_7” and production calls it “ASSET-007,” how do we establish that they mean the same physical asset? And if two plants both have a “Machine 07,” what keeps us from combining their histories? Stable identities, mappings back to source identifiers, and a review process for uncertain matches become essential. Units and time zones need the same attention.

This was where the work started looking very familiar again. People from operations, data management, and engineering need to agree on definitions, establish which system is authoritative for each fact, and decide who resolves disagreement. The discussion about technology eventually reaches the question of who knows the operation well enough to say whether the information is right.

Architecture choices and building the graph

Once I could picture the model, I found myself wondering what an implementation would look like alongside the systems a manufacturer already owns. Would it require copying everything into another database? What about all the sensor readings? I could understand why someone might hesitate if the proposal sounded like rebuilding their entire data environment. Thinking it through, I kept coming back to a few practical decisions:

  • Where the data lives. A materialized graph stores selected information in a graph store, which brings responsibility for keeping it synchronized. A virtual knowledge graph can expose data through mappings and translate graph queries into queries against existing databases. That reduces copying, but the sources still determine what is available and how quickly it can be retrieved. A hybrid approach can store frequently used relationships and retrieve other details when needed.

  • How the graph fits with existing systems. For an industrial application, I would generally expect transaction processing to stay with the systems that own it, while high-volume measurements remain in historians or time-series platforms. The graph can connect assets, events, documents, and relevant measurement ranges without becoming the destination for every reading. My background in digital infrastructure makes me pay attention to that boundary: moving information reliably and agreeing what it means are both necessary, and solving one doesn't finish the other.

  • Which graph model to use. I also had to get comfortable with the differences between RDF, which expresses facts as subject-predicate-object statements and is commonly queried with SPARQL, and property graphs, which represent nodes and typed relationships with properties on both. Those choices affect interoperability, tooling, validation, and any rule-based inference the application needs. I can get carried away comparing the details, but I would want the decision grounded in real queries and the team's ability to operate the result.

  • How it is operated and governed. The operating questions matter just as much: cloud or on-premises placement, connectivity, latency, recovery, and access controls. Combining information must preserve the restrictions on who can see it. A centrally managed graph and graphs owned by individual business domains are both possible, provided they share identifiers and meanings where they connect. Someone still needs responsibility for changing those definitions without breaking other people's applications.

  • How data is mapped and validated. Getting the information into the model requires a repeatable process: collect records, normalize values, resolve identities, map relationships, validate, and publish them for use. Mappings and transformation rules need version control so changes can be tested and reversed. SHACL can validate RDF against specified conditions, while property graph platforms offer their own constraints. I would also test against known outcomes, including missing links, duplicates, and rework, because a record can satisfy every structural rule and still describe the wrong machine.

Documents introduce another possibility. Microsoft's GraphRAG work explored extracting relationships and summaries to support broader questions, and its indexing pipeline shows how language models can help. I find that promising, but I would keep extracted claims distinguishable from verified operational records, with their sources attached and review appropriate to how the answer will be used.

Keeping the graph current and trustworthy

The detail I kept returning to was time. Suppose a component was replaced yesterday and we are investigating something produced last week. The current relationship between the component and the machine could be perfectly accurate and still be the wrong relationship for that investigation. I had started with a simple connection between two things, and now I wanted to know when the connection began, when it ended, and when the system learned about the change. This is important because when information arrives late or someone corrects an old record. Depending on the use case, the model needs to preserve when a relationship was valid, when the source recorded it, and when the graph received it. Overwriting the current value can remove the very history needed to explain what happened. It also made me wonder how often an apparent disagreement between systems is really a disagreement about time.

Keeping the graph current therefore needs to be part of the design from the beginning. Scheduled loads, APIs, events, and change data capture provide different ways to bring changes through. A planning analysis might tolerate a daily refresh, whereas an active quality investigation may need much fresher information. Updates and deletions matter alongside new records, and retrying a failed operation should not create duplicate relationships.

I would want to retain provenance, so someone can inspect where an answer came from and how it was derived. That means revisiting inferred relationships, summaries, and indexes when their supporting evidence changes. An AI summary could remain outdated after the graph beneath it has been corrected, which is another dependency I wouldn't want to discover only after someone relied on the answer. This is also why ownership and monitoring deserve an operating budget. Someone needs to watch update lag, failed loads, unresolved identities, and gaps in source coverage, reconcile the graph with authoritative systems, and maintain mappings as those systems change. An absent relationship may mean something never happened, or simply that its record never arrived. Users need a way to understand that uncertainty and report errors back into the process.

Using the graph and measuring its value

After spending time on these details, I come back to the quality engineer trying to determine which orders might be affected. That person may need an evidence-backed list inside an existing application, with a clear next step. The graph can support that through queries, APIs, search, or an assistant, without requiring everyone to learn how to navigate a network diagram. For AI, I would combine graph queries with document retrieval and conventional database queries wherever each helps, then test the answers and their evidence. Better context doesn't guarantee correctness, and finding an affected order doesn't authorize an agent to put it on hold. I would measure investigation time, missed and falsely flagged orders, adoption, and the cost of maintaining reliable answers, comparing the result with the tools already in use.

I still have more to learn, but I now understand why the easy explanation left me with so many questions. Knowledge graphs made sense to me quickly because the relationships were familiar; appreciating what it takes to represent them consistently required looking much more closely at how our systems work. That has made me more interested in them, and more thoughtful about where I would start: one question that matters to someone, with an answer we can follow back to the evidence and continue to trust as the business changes.

References:

Jeff Winter
Next

Digital Debt: When “Just for Now” Becomes Critical Infrastructure