Why the future of data engineering lies in uniting structure with meaning
The Growing Divide Between Structure and Meaning
In data engineering, we’ve long mastered the structure of data — tables, schemas, transformations, lineage. What we’ve struggled with is meaning.
A recent piece by Michel Sauvage — “Ontology vs Data Model” — reignited an old but essential debate: Have we confused organizing data with understanding it?
Sauvage reminds us that a data model organizes facts, while an ontology explains what those facts mean. A schema can ensure referential integrity, but it cannot tell us that a Customer is a kind of Party, or that Software and Hardware are disjoint classes in a logical sense.
In other words, data models describe, but ontologies assert. And if our modern data platforms stop at description, we risk building systems that are structurally sound — yet semantically hollow.
From Metadata-Driven to Meaning-Driven
Over the past years, many of us have embraced metadata-driven frameworks to automate data ingestion and transformation.
Instead of hardcoding pipelines, we define metadata — models of sources, targets, mappings, and rules — and feed them into a runtime engine that generates SQL or Python workflows dynamically.
This shift has been transformative. But as I reflected on Sauvage’s argument, I realized: our metadata itself could become smarter.
Today, it describes how data should flow.
Tomorrow, it could also describe why.
That’s where ontology thinking comes in.
The Three Layers of Modeling
Sauvage’s article draws a powerful distinction between meta-model, data model, and ontology — a triad that maps beautifully to how modern metadata-driven architectures evolve:
In practice:
Your metadata already acts as a meta-model and data model.
By adding an ontological layer, you enable reasoning — a way for your system to interpret relationships and business meaning, not just data lineage.
Closed World vs Open World Thinking
Most data systems live in what ontology engineers call a Closed World — if a fact isn’t in the database, it’s considered false. This is efficient for transactions, but limiting for knowledge.
Ontologies operate in an Open World — what isn’t known is simply unknown, not false. This mindset is crucial when integrating partial or evolving truths across multiple systems — precisely what we do in historized, bi-temporal data vaults or integration layers.
Seen this way, bi-temporal modeling is already ontology-inspired. It acknowledges that knowledge changes over time, and that multiple truths can coexist depending on temporal context.
Declarative Pipelines as Semantic Engines
When we describe a pipeline declaratively — “select attributes from this source, apply this rule, join with that lookup” — we’re not writing code; we’re writing a theory of transformation.
At runtime, our engine interprets that theory, compiles it into SQL, and executes it. That’s not far from what an ontology reasoner does: it takes formal assertions and derives new truths.
The next evolution of metadata-driven frameworks may thus look like this:
- Input: Declarative metadata enriched with ontological meaning
- Runtime: A “semantic compiler” that transforms logical rules into executable workflows
- Output: Data pipelines that are not just automated, but aware — aware of business concepts, domain semantics, and temporal logic.
From Pipelines to Knowledge Graphs
Once metadata and ontology converge, our lineage and data quality frameworks change fundamentally. A simple data lineage diagram shows where data flows.
A semantic lineage diagram shows why — under what conditions, based on which conceptual relationships, and with what business intent.
This idea connects with what I’ve called context-aware lineage:
If a dataset is unioned or filtered, lineage should not just say “data flows here,” but “data flows here when condition X is true.”
That is semantic awareness — a small but critical step toward reasoning.
And that reasoning is what powers the next generation of knowledge-driven data platforms.
Why This Matters
For years, data engineers have fought to reduce manual coding, standardize naming, and enforce consistency.
Metadata-driven design has given us automation.
Ontology will give us understanding.
- It helps prevent logical contradictions across domains.
- It allows rules to be declared once and reused everywhere.
- It lays the foundation for machine reasoning — and eventually, for AI-native data governance.
In short, ontology turns our metadata from a registry into a knowledge base.
Closing Thought
Sauvage ends his essay with a sentence that stuck with me:
“Failure to distinguish the model of structure from the model of meaning condemns us to manage data without ever truly understanding it.”
Our metadata frameworks are powerful.
But if we want data platforms that are truly intelligent — not just automated — we must now bridge that gap.
We must let our metadata speak the language of meaning.
That bridge is ontology.
And that’s where the next generation of semantic data platforms will begin.
💡 Related reading: Declarative Pipelines in Databricks — The Execution Layer of Our Metadata-Driven Architecture
Beyond the SELECT Clause: The Hidden Depths of Column Lineage
For more on semantic lineage and metadata frameworks, follow the Model-Driven Data Architecture series.