Knowledge Graphs: Connecting Data, Relationships and Context

What Are Knowledge Graphs?

The research literature does not use a completely uniform definition. Hogan et al. deliberately define a knowledge graph broadly as a graph of data intended to accumulate and convey knowledge of the real world. Its nodes represent relevant entities, and its edges represent relationships between them.^[1] What matters, then, is not a particular software product or notation. It is the explicit connection of data, relationships, and meaning.

A knowledge graph is therefore more than a graphical representation of existing tables. It represents a domain context in a way that allows individual statements to be connected, interpreted across multiple sources, and queried for specific purposes.

From Material Through Its Use to the Product Batch

An illustrative query asks: Which product batches were processed using material batch M-204? The graph needs more than a list of materials with the same name. It must connect the specific material identity to its uses and the affected product batches.

One possible path leads from M-204 to task A-17 and from A-17 to product batch C-24. The relationship to the material batch is named “uses,” and the relationship to the product batch is named “processes.” Another task, A-18, can use the same material for C-25. The query follows these relationships and returns the product batches connected in this way.

An “intended material” reference would express a different statement. C-24 may also be reachable through several tasks. If each affected product batch is to appear only once, the query must account for its identity accordingly. The result therefore depends on the meaning of the relationships and the query rule.

The path describes a use, not a proven cause of an error. If M-204 is investigated later, the batches found can provide a starting point for further review. Whether they are actually affected is an additional domain question.

Nodes, Edges, and Statements

The basic principle can be read as a statement in three parts:

A simple example is: “Task 4711 uses material batch M-204.” The task is the subject, “uses” is the relationship, and the material batch is the object. Further statements can supplement the same node: the task follows SOP version 7, takes place in room R-12, is performed by the Production role, and produces measurement value W-88.

RDF, the W3C Resource Description Framework, formalizes this basic pattern as a subject-predicate-object triple. A set of these triples forms an RDF graph. The W3C describes it as a directed node-arc diagram; identifiers, literals, and blank nodes can serve different functions within it.^[2]

Knowledge graphs do not necessarily have to use RDF. Property graph models can also add properties to nodes and edges. The choice of model depends on the queries, integrations, and tools required.^[1] RDF matters here because it provides a standardized example of explicitly describing resources and relationships—not because every knowledge graph must have an identical technical structure.

Identity Connects the Same Real Objects

A graph becomes reliable only when it is clear which node denotes which real object. The same material batch can have different names in purchasing, inventory, the production order, and the test report. Treating these names as four objects without review does not produce a connected picture. Conversely, incorrectly merging different real batches connects statements inaccurately.

RDF uses IRIs as identifiers intended to have global scope. Two occurrences of the same IRI generally denote the same resource.^[2] Internal knowledge graphs can use other identification methods. The domain problem remains the same: identities need stable rules, unambiguous keys, and controlled mapping between source systems.

Resolving identity is therefore not cosmetic data cleaning. It determines whether questions can be answered meaningfully across system boundaries. A correct link makes it possible, for example, to connect the purchase of a material batch to its inventory receipt, actual consumption, and the resulting product states.

Why Isolated Records Are Not Enough

A batch number, a consumption value, or a test result can be correct on its own yet explain little. Its informational value emerges only through context: Which product does the batch belong to? During which task was the material consumed? Which SOP version applied? Who performed the step, who reviewed it, and which release followed?

Relational data models can also explicitly represent domain relationships and connect them through keys. Problems arise when identities or meanings are not aligned across datasets. A knowledge graph offers a graph-based representation for this purpose: objects and named relationships form paths along which connected statements can be queried. Here too, domain meaning must be deliberately modeled.

This is particularly relevant when data from several areas are combined. Hogan et al. identify schema, identity, and context as central tasks in building a knowledge graph: a schema describes the overarching structure, identity clarifies which names refer to the same real object, and context defines the circumstances under which a statement applies.^[1]

Context Prevents Overstated Claims

A relationship can be misleading without its scope of applicability. “Batch A is released” remains incomplete if it is unclear to which process stage, market, review decision, or point in time the statement applies. Responsibilities, SOP versions, and limits also change.

A knowledge graph must therefore not only store relationships but also model a statement's context where needed. Options include named graphs, separate event or decision objects, timestamps, and references to the underlying source. According to the W3C, RDF itself is an atemporal data model: a graph initially describes a static information state. Temporal aspects and events can be expressed using suitable vocabularies, but they must be explicitly modeled.^[2]

This marks an important distinction from process history. A knowledge graph can represent historical statements and their relationships. It does not, however, automatically replace the recording of complete process events or reliable evidence of changes.

Checking Expected Relationships Before the Query

For the path through A-17, the task must have a traceable connection to the material used and the product processed. If either relationship is missing, the query may overlook C-24. A structural rule can check precisely these expected data.

SHACL formulates such conditions for RDF graphs.[4] Passing a structural test does not, however, show that A-17 actually used M-204. It checks the stated expectation for the stored representation; the correctness of the assignment needs its own basis.

Schema, Ontology, and Specific Statements

A knowledge graph can contain statements about individual objects and general concepts. A schema describes the intended object types and relationships. These levels can be distinguished without completely separating them technically. It can specify, for example, that a task uses an SOP version, consumes a material batch, and is performed by a role.

Ontologies can give this model of concepts and relationships greater formal precision. According to the W3C specification, OWL 2 is a declarative language for describing ontologies. It can express concepts, relationships, and logical statements in a way that enables software to derive further information from them. In addition to general concepts, an OWL ontology can contain statements about specific individuals.^[3]

Not every knowledge graph needs an extensive ontology. A simple, controlled schema may be sufficient for a limited use case. Formal rules become valuable where concepts need to be understood unambiguously across systems, contradictions identified, or inferences derived reproducibly. Developing such a formal conceptual model is, however, a separate task and is not accomplished merely by building a graph.

From Structured Data to Context That Can Be Analyzed

Knowledge graphs do not generate missing operational data by themselves. They need structured, identifiable inputs. Free text can provide clues, but reliable relationships arise only when relevant objects, events, roles, and states are unambiguously captured or extracted from sources in a controlled manner.

A graph does not replace every existing data structure either. Quantity transactions, measurement series, or document files can remain in specialized systems. The knowledge graph can describe their identity, meaning, and connection and refer to the respective source. This creates a semantic linking layer without forcing all data into the same storage format.

This connection is particularly useful for Process Intelligence. Analysis results can be investigated not only by grouping table fields but also along domain relationships: by product, batch, material, role, task, release, or SOP version. The prerequisite remains that these relationships are correctly modeled in domain terms and populated from reliable data.

What a Knowledge Graph Provides—and What It Does Not

A carefully constructed knowledge graph can bring heterogeneous data into a shared domain context. It facilitates queries across system boundaries, reveals indirect relationships, and creates a foundation for search, analysis, assistance, and controlled inference. New data sources can be added without rebuilding every existing application around the same internal model.

It is not, however, automatically complete or objective. Modeling decisions determine which objects and relationships become visible. Identity errors can merge data incorrectly. Outdated statements remain outdated if updating and validity are not governed. Logical inferences are only as sound as the underlying statements and rules.

A knowledge graph is also no substitute for permissions, versioning, an audit trail, approval procedures, or domain responsibility. It can represent their relationships and make them available for analysis. Operational controls must nevertheless remain embedded in the executing systems.

A Useful Graph Makes the Answer Traceable

The query for M-204 returns more than batch identifiers. Through the tasks and named relationships, it is possible to check why C-24 or C-25 appears in the result. A missing or incorrectly named reference changes that answer.

The value of a knowledge graph therefore becomes apparent through specific questions and their traceable paths. Identities, relationship meanings, and scope of applicability must support these paths; the number of stored nodes alone says little about them.