Knowledge Graphs and Semantic Data

A knowledge graph is a structured representation of entities and the relationships between them, enriched with identifiers, types, provenance and rules that make meaning more explicit for both people and machines. Semantic data is data whose concepts and relationships are represented clearly enough that systems can interpret more than isolated fields and values.

A graph becomes useful when it preserves not only that two things are connected, but what kind of connection exists, under which evidence, and in which context.

Traditional tables are powerful, but many real-world questions are relational. Which author wrote which publication? Which student belongs to which class during which dates? Which supplier provides components used in which products? Which research result depends on which dataset, instrument and method? Knowledge graphs make those relationships first-class objects rather than hiding them inside joins that each consumer must reconstruct independently.

ARTICLE ID: DATA.MANAGEMENT.036
Canonical function: entity–relationship meaning, graph representation and machine-readable semantic connectivity
Series route: Data Modelling and Schema Design → Knowledge Graphs and Semantic Data.

The Simple Answer

A knowledge graph represents the world as connected statements:

Entity → Relationship → Entity

For example:

Student A enrolled in Class X;
Book B written by Author C;
Dataset D derived from Dataset E;
Product P supplied by Supplier S;
Article Q cites Publication R.

The graph becomes more powerful when entities and relationships have stable identity, type, provenance, time and governed definitions.

Why Relationships Matter

Many data systems store facts as separate records and leave relationships implicit. A graph makes connections explicit so they can be traversed, queried and governed directly.

This helps with questions such as:

What depends on this dataset?
Which products use this supplier?
Which articles reference this concept?
Which students were in this class when an assessment occurred?
Which systems can access this sensitive record?
Which sources support this claim?

Nodes, Edges and Properties

In graph terminology, nodes represent entities or concepts and edges represent relationships. Properties can describe either.

Student node: ID, name, status;
Class node: code, subject, year;
Enrolled-in edge: start date, end date, source record.

Putting dates on the relationship rather than only on the student or class can preserve historical membership accurately.

Identity Before Connectivity

A graph is only as trustworthy as its entity identity. If the same organisation appears under several names without reconciliation, the graph fragments one real entity into several nodes.

Stable identifiers and entity-resolution rules are therefore foundational.

See Master Data and Reference Data.

Aliases

Entities often have multiple names, abbreviations, historical names or language variants. A knowledge graph can preserve aliases while keeping one canonical identity.

This separates what something is called from which thing it is.

Types

Types describe what kind of entity or relationship is represented: Person, Organisation, Dataset, Publication, School, Product, Location, Event.

Typing helps machines distinguish relationships that would otherwise look similar. “Member of” between a person and an organisation differs from “part of” between a component and a product.

Ontologies

An ontology defines concepts, relationships and constraints in a domain. It can express that:

a Teacher is a type of Person;
a Publication may have an Author;
an Enrolment connects a Student and a Class;
a Dataset can be derived from another Dataset;
a City is located in a Country.

Ontologies should serve real interoperability and reasoning needs. Excessive formalisation can become difficult to maintain.

Taxonomy vs Ontology

A taxonomy mainly organises categories into hierarchies. An ontology can represent richer relationships and constraints between concepts.

A taxonomy might say Biology is under Science. An ontology can additionally represent that a Research Paper studies an Organism using a Method and produces a Dataset.

Triples

One semantic graph pattern represents statements as triples:

Subject → Predicate → Object

For example:

Dataset-42 → derivedFrom → Dataset-17

Large knowledge graphs can contain millions or billions of such statements, each addressable through stable identifiers and shared vocabularies.

RDF-Style Graphs

RDF-style semantic graphs represent statements through globally identifiable resources and predicates. This supports linked-data patterns where different datasets can refer to the same concepts or identifiers across system boundaries.

The value lies in interoperability and explicit semantics, not in the acronym itself.

Property Graphs

Property-graph models represent nodes and edges with attached properties. They are commonly useful for operational traversal, recommendation, network analysis and relationship-heavy applications.

RDF-style graphs and property graphs solve overlapping but not identical jobs. Architecture should follow query, interoperability and governance requirements rather than treating one model as universally superior.

Linked Data

Linked-data approaches use stable web identifiers and explicit relationships so independently published resources can connect without copying all data into one database.

The principle is powerful: connect by identity and semantics while preserving distributed ownership.

Identifiers as Bridges

Graphs become interoperable when entities can be referenced consistently across datasets. Persistent identifiers for publications, researchers, places, organisations or internal master entities reduce reconciliation work.

An identifier should point to one intended entity and remain stable enough for long-lived references.

Semantic Vocabularies

Shared vocabularies define relationship and attribute meaning. They can prevent two teams from using the same word for different relationships—or different words for the same relationship without a crosswalk.

Vocabularies require governance because terms evolve.

Crosswalks

When two vocabularies differ, crosswalks can map related concepts. Mappings should distinguish exact equivalence from broader, narrower or approximate relationships.

False equivalence is one of the most damaging semantic errors because it makes integrated data appear cleaner than reality.

Provenance

A graph statement should be able to carry provenance: which source asserted the relationship, when it was observed, which process produced it and who is responsible.

This matters when several sources disagree.

See Metadata and Data Lineage.

Claims vs Facts

Some relationships should be represented as claims rather than unquestioned facts. Source A may claim that Entity X is related to Entity Y while Source B disputes it.

A mature knowledge graph can preserve source, confidence and disagreement instead of collapsing uncertainty into one edge.

Temporal Graphs

Relationships change through time. People join and leave organisations. Countries change boundaries. Products change suppliers. Students move classes.

Temporal graphs attach effective dates or validity intervals to nodes and edges so historical queries can ask what was true at a particular time.

Current State vs Historical State

Overwriting an old edge with a new one destroys history. Versioned graph models preserve both current relationships and the path by which they changed.

This aligns with broader temporal data modelling.

Events in Knowledge Graphs

Events can be represented as first-class entities linking participants, places, times and consequences.

Instead of one edge saying Person A “workedAt” Organisation B, an Employment event can carry start date, end date, role, source and uncertainty.

Reification and Relationship Metadata

Sometimes a relationship itself needs rich metadata. Graph models provide several ways to represent statements as addressable objects so provenance, time or confidence can attach to them.

The representation should remain understandable to the systems that need to query it.

Graph Queries

Graph query languages are designed to express pattern and traversal questions:

find suppliers connected to products affected by a recall;
find publications two citation hops from a source;
find students connected to a curriculum unit through classes and assessments;
find datasets derived from a sensitive source;
find systems reachable from a compromised credential.

Graphs can make multi-hop relationships easier to express than repeated relational joins, though relational systems remain excellent for many tabular jobs.

Traversal

Traversal follows edges from one node to related nodes. Bounded traversal is important because real graphs can become enormous and cyclical.

Query design should define depth, relationship types and stopping conditions rather than treating every reachable connection as equally meaningful.

Connectivity Is Not Causality

A graph shows that entities are connected according to represented relationships. It does not prove that one entity caused another.

Two-hop reachability is not causal evidence. Semantic graphs should resist turning network proximity into unsupported explanation.

Inference

Some semantic systems can infer additional statements from explicit rules and class relationships.

For example, if every Secondary Teacher is a Teacher and Person A is a Secondary Teacher, the system may infer that Person A is a Teacher.

Inference should remain traceable to its rule and source assumptions. Derived statements are not identical to observed statements.

Constraints

Graphs need validation just as tables do. Constraints can require that certain entity types have required properties or that relationships connect appropriate classes.

Validation reduces semantic drift and structurally impossible graphs.

Graph Data Quality

Graph quality includes:

entity-resolution accuracy;
relationship validity;
type consistency;
provenance completeness;
temporal correctness;
duplicate-node control;
ontology alignment;
orphan-node review;
stale relationship detection.

A graph with beautiful connectivity can still encode wrong identities and therefore spread error rapidly.

Entity Resolution

Entity resolution determines whether two records refer to the same real entity. This can use exact identifiers, rules, probabilistic matching or human review.

False merges are often worse than leaving uncertain entities separate because one wrong merge contaminates every connected relationship.

Confidence

Some graph edges come from deterministic records; others come from probabilistic extraction or inference. Confidence metadata can help consumers distinguish the two.

A confidence score should be interpreted according to how it was generated rather than treated as universal truth.

Knowledge Graphs and Data Integration

Graphs can serve as an integration layer across heterogeneous systems by connecting identities and relationships without forcing every source into one physical schema.

This does not eliminate data integration work. Source mappings, identifiers, provenance and semantic crosswalks are still required.

See Data Integration and Interoperability.

Knowledge Graphs and Semantic Layers

A semantic layer for analytics defines measures, dimensions and business calculations. A knowledge graph represents richer entity and relationship meaning.

They can complement each other. The graph can describe entity relationships while the semantic layer governs analytical metrics over those entities.

See Semantic Layers and Metric Governance.

Knowledge Graphs and Catalogues

Data catalogues themselves can be graph-like because datasets, owners, systems, terms, metrics and lineage form a network of relationships.

A graph can power discovery questions such as “Which certified metrics depend on this source table?”

Security Graphs

Identity, roles, permissions, systems and resources naturally form graphs. Security teams can use graph traversal to identify indirect access paths or privilege relationships.

Because security graphs can reveal sensitive architecture, access to the graph itself should be governed.

Supply-Chain Graphs

Suppliers, components, products, factories, shipments and certifications can be connected into supply-chain graphs. Multi-tier dependencies become easier to traverse when a disruption occurs.

The graph still depends on completeness: unknown lower-tier suppliers create blind spots.

Research Knowledge Graphs

Research graphs can connect publications, authors, institutions, datasets, methods, grants and citations.

They can improve discovery and provenance while preserving the distinction between a publication, its supporting dataset and claims derived from it.

Education Knowledge Graphs

An education graph can connect syllabus concepts, prerequisite skills, lessons, questions, assessments and learning resources.

A learner struggling with one concept can be connected to prerequisite nodes and supporting materials without reducing the learner to one permanent label.

Knowledge Graphs and AI

AI systems can use knowledge graphs for retrieval, entity resolution, structured tool use and grounded reasoning over known relationships.

A graph can help an AI distinguish:

an entity from an alias;
a source from a derived claim;
a current relationship from a historical one;
a canonical identifier from a mention;
a direct relationship from a multi-hop inferred path.

Graph Retrieval vs Vector Retrieval

Vector retrieval finds items with similar numerical representations. Graph retrieval follows explicit relationships. They answer different questions and can be combined.

A vector system may find documents semantically similar to “photosynthesis”. A graph may identify that Photosynthesis depends on Light Reactions and Carbon Fixation and is taught in a particular syllabus unit.

Similarity is not the same as relationship.

Graph-Augmented Retrieval

An AI retrieval system can resolve entities first, traverse a bounded graph to identify relevant neighbours, then retrieve supporting documents for those nodes.

The graph should guide discovery without becoming a source of unsupported facts. Retrieved evidence should remain attached to authoritative sources.

Graph Embeddings

Graph structures can also be represented numerically for machine-learning tasks. These embeddings compress relationship patterns into vectors.

The embedding is a derived representation, not a substitute for the original graph’s explicit provenance and semantics.

Knowledge Graph APIs

Graph data can be exposed through APIs that return entities, relationships or bounded subgraphs. API contracts should protect graph complexity and prevent unrestricted traversal from becoming a security or cost problem.

See Data APIs and Data Services.

Privacy

Graphs can increase privacy risk because relationships reveal context. A dataset containing harmless individual attributes may become sensitive when relationships expose family, social, educational or organisational connections.

Classification should consider both nodes and edges.

Access Control

Graph access can be difficult because a user allowed to see one node may infer sensitive information through connected nodes.

Security design may need node, edge, property and traversal-level controls depending on consequence.

Graph Versioning

Ontologies, vocabularies and entity mappings change. Graph versioning should preserve when relationships were asserted, corrected or retired.

See Data Versioning and Change Management.

Testing Knowledge Graphs

Useful graph tests include:

identifier uniqueness;
type constraints;
relationship-domain and range checks;
orphan detection;
duplicate entity detection;
temporal consistency;
provenance completeness;
ontology compatibility;
known traversal cases;
access-control tests.

See Data Testing and Reliability Engineering.

Operational Knowledge Graphs

Operational graphs need freshness, change capture and observability just like other data products. Stale edges can be worse than missing edges because they appear authoritative.

Owners should know how source-system changes propagate to the graph and how corrections are replayed.

Graph Stewardship

Graph stewards maintain vocabularies, mappings, identity rules and relationship semantics. Because one semantic decision can affect many downstream traversals, stewardship is especially important.

See Data Stewardship and Ownership.

Do Not Model Everything

Knowledge graphs can tempt teams to model the entire world before delivering value. That creates ontology programmes that grow faster than useful applications.

Start from receiver questions and model the entities, relationships and evidence needed to answer them.

Graph Boundaries

Every graph is partial. It contains what the organisation chose or managed to represent. Missing edges can mean “not connected”, “not yet observed”, “not permitted to reveal” or “outside scope”.

Absence should not automatically be interpreted as a negative fact.

Unknown and Disputed Relationships

Mature graphs should preserve unknown, disputed and provisional states where the domain requires them. Forcing every relationship into true or false can erase legitimate uncertainty.

Common Failure Modes

Graph equals truth: represented relationships are treated as reality without provenance.
Identity fragmentation: one entity appears as many nodes.
False merge: similar entities are collapsed incorrectly.
Connectivity equals causality: multi-hop paths become unsupported explanations.
Ontology overreach: years are spent modelling concepts nobody uses.
Current-state overwrite: historical relationships disappear.
Edge without source: nobody knows why the relationship exists.
Similarity equals relationship: vector closeness is treated as semantic linkage.
No access model: graph traversal reveals sensitive indirect relationships.
Unknown equals false: missing edges are interpreted as proof of no relationship.

A Knowledge Graph Checklist

What receiver questions require a graph?
Which entities need stable identity?
Which aliases must resolve to canonical entities?
Which relationship types matter?
What ontology or vocabulary is required?
Which mappings are exact vs approximate?
How is provenance attached to statements?
How are time and historical states represented?
How are uncertainty and disputed claims represented?
Which graph model best fits the job?
How is quality tested?
How is access controlled across nodes and edges?
How do source changes propagate?
Which APIs or AI systems consume the graph?
Can a receiver trace a graph statement back to evidence?

A Maturity Ladder

Connected: entities and relationships are represented.
Identified: stable identity and aliases are governed.
Typed: vocabularies and relationship meanings are explicit.
Provenanced: graph statements retain source evidence.
Temporal: changing relationships preserve history.
Validated: constraints and entity-resolution quality are tested.
Interoperable: identifiers and vocabularies connect across systems.
Machine-actionable: APIs, analytics and AI can traverse the graph without losing provenance or semantic boundaries.

The Deeper Principle: Meaning Lives in Typed Relationships

A knowledge graph is not valuable because it draws lines between things. Lines are cheap. Meaning comes from stable identity, explicit relationship types, provenance, time and the discipline to preserve uncertainty where the world is uncertain.

When those properties are present, a graph becomes a machine-readable layer of organisational memory: not a replacement for source evidence, but a navigable representation that helps people and machines find how the evidence is connected.

Data Management Series

Final idea: knowledge graphs make relationships explicit enough to traverse, govern and reuse. Their real power is not connectivity alone but the preservation of identity, semantics, provenance and time so machines can navigate organisational knowledge without mistaking representation for reality.

Knowledge Graphs and Semantic Data | Entities, Relationships, Ontologies, Linked Data and Machine-Readable Meaning