From Data Engineering to
Knowledge Engineering
in the blink of an eye

Veronika Heimsbakk · JavaZone 2026

About me

veronahe.no

From Data Engineering to
Knowledge Engineering
in the blink of an eye

Veronika Heimsbakk · JavaZone 2026

Assumption

Data Engineer

Data engineers move data, structure data, and keep data trustworthy.

dbt Airflow Spark Polars SQL Snowflake Databricks Kafka

Assumption

Knowledge Engineer

Knowledge engineers capture human understanding, formalise it, and make it usable for intelligent systems.

Protégé OWL SHACL SPARQL RDF Jena RDF4J maplib

So, why should you care?

Why should you care?

Three sources, one question

You have a band encyclopedia, a vinyl store, and festival lineups.

Someone asks: "What albums should I grab for the Roadburn lineup?"

One simple question that spans three sources with three schemas. That's three different column names for the same band.

bands.csv         →  "name"
vinyl_store.csv   →  "artist"
festival_lineups  →  "performer"

Why should you care?

The JOIN problem

You write a pipeline. LEFT JOIN on name. But one source spells it "Post-Rock", another "Post Rock". You add COALESCE. You add fuzzy matching. It works... until next week.

Every JOIN is a confession that your data model threw away a relationship that you now need back.

The pipelines get longer, the joins get more fragile, and the "simple questions" keep taking longer to answer.

Why should you care?

What if relationships were first-class?

Instead of tables with foreign keys, you have things and relationships between things, stated explicitly:

Nine_Inch_Nails       hasAlbum    The_Downward_Spiral
The_Downward_Spiral   price       41.99
Nine_Inch_Nails    playsAt      Hellfest

Three sources map to the same identifier for Nine Inch Nails. The data merges the moment it enters the graph. No JOINs, COALESCE, or fuzzy matching.

Why should you care?

The ontology: schema, docs, and shared vocabulary in one

An ontology defines what types of things exist, what relationships are valid, and what properties they can have.

It's your data contract, but one that machines can actually enforce and reason about.

In SQL the schema lives in information_schema, separate from your data. In a knowledge graph, the ontology is data. Same query language. Same graph.

Why should you care?

This means that...

  • Merging datasets is free. Same identifier = same node. No join keys or fuzzy matching.
  • Schema evolution doesn't break anything. Adding new types of facts doesn't require altering existing ones.
  • Validation is declarative. Define shapes that describe what valid data looks like, similar to SQL constraints but for graphs.
  • Meaning is machine-readable. What is a Band? What is a valid Album? The ontology answers this, and your code can use it.

Why should you care?

"Okay, but RDF is slow, verbose, and nobody uses it"

"It's slow"

Modern tools are built on Apache Arrow and Rust. Same columnar engine as Polars. DataFrame speed.

"It's verbose"

You don't read Parquet files either. You work with DataFrames. The serialisation is handled for you.

"Nobody uses it"

Google's Knowledge Graph. Wikidata. The entire EU railway framework. Energy (CIM), healthcare (FHIR), finance (FIBO).

veleda.github.io/rdf-vendor-landscape

Why should you care?

The AI elephant in the room

AI agents don't just generate text. They make decisions, take actions, and operate across your business.

An LLM can generate a fluent answer. But fluency is not accuracy.

When your agent decides to shut down a pump, reorder inventory, or escalate a complaint, it needs to know what a pump is, which system it belongs to, and what rules apply.

Knowledge graphs give AI agents what they desperately lack: structured understanding of your domain.

Why should you care?

Knowledge graphs need you

Knowledge graph projects fail without data engineers.

Ontologists design beautiful models. But they don't move data. They don't build pipelines. They don't handle schema drift or operationalise anything at scale. You do.

The tooling gap has been the barrier. You should be able to build a knowledge graph with the languages and tools you already know: Python, DataFrames, and familiar APIs.

The two things you need to know
about knowledge graphs

Two things you need to know

1. Triples

Every fact is stored as three parts: subject, predicate, object.

The Downward Spiral Nine Inch Nails artist

Always three parts. That's the entire data model.

Two things you need to know

2. IRIs

Every thing and every relationship gets a globally unique identifier.

Same identifier = same node in the graph, no matter which source it came from.

http://example.org/music/album/The_Downward_Spiral
http://example.org/music/artist
http://example.org/music/band/Nine_Inch_Nails

How to make it happen?

Demo time

pip install maplib

Summary

  • Three sources, three schemas, one graph, no JOINs
  • OTTR templates map DataFrame rows to triples
  • Shared IRIs connect everything automatically
  • SKOS vocabulary harmonises messy strings
  • Ontology = living schema + documentation + shared vocabulary
  • SPARQL queries across all sources, and results are Polars DataFrames
  • Knowledge graphs are necessary for AI, and they need data engineers
pip install maplib

veronahe.no  ·  github.com/DataTreehouse/maplib