Ontology-Based Data Integration Explained

Every data team eventually inherits the same problem. Customers live in the CRM, invoices in the billing system, usage in an event warehouse, and support tickets in a SaaS tool. Each source has its own keys, its own column names and its own idea of what a customer is. Ontology-based data integration tackles this by mapping every source to one shared model of the business, then letting people and applications query that model instead of the individual systems.

What follows covers the ontology, the mappings and the query engine. It is part of the series that begins with ontology in data and AI, which covers why a shared model of meaning matters. Here the focus is practical: the architecture, a worked mapping example, the decision between virtualizing and materializing, and the mistakes that sink projects.

What is ontology-based data integration?

Ontology-based data integration connects several data sources through a single domain ontology. The research literature usually calls the querying side ontology-based data access, or OBDA. The IJCAI 2018 survey by Xiao, Calvanese and colleagues describes three parts:

An ontology that defines the business concepts and relationships, such as Customer, Invoice and billedTo.
The data sources, usually relational databases, left in place.
Mappings that say how rows and columns in each source become instances and properties of the ontology.

A user writes a SPARQL query against the ontology. The system uses the mappings to rewrite it into SQL for each source, runs it, and returns results in terms of the ontology. Nobody has to know that "customer" is crm_accounts.account_id in one system and billing_invoices.crm_ref in another.

In a 2019 overview in Data Intelligence, Xiao, Ding, Cogrel and Calvanese, of the Free University of Bozen-Bolzano group behind the open-source Ontop system, described the same idea as a virtual knowledge graph: a knowledge graph exposed over data that stays in its original sources, with queries translated at run time. The two names describe the same architecture, seen from the query side and the graph side.

Why not just build another warehouse?

A warehouse also integrates sources, and for many analytics needs it is the right answer. The difference is where the meaning lives. In a warehouse, meaning is spread across transformation code, table names and documentation. In ontology-based data integration, meaning is a first-class artifact: an explicit model that people can read, review and reuse, and that every mapping must target.

That matters most when the questions cross many domains, when sources change often, or when several consumers (BI tools, APIs, LLM applications) need the same definitions. It matters less when you have three sources and one dashboard.

The architecture, layer by layer

The ontology

The ontology sits at the top. It should describe the business, not any one system. A small core is enough to start:

@prefix ex:   <https://data.example.com/ontology#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Party    a owl:Class .
ex:Customer a owl:Class ;
    rdfs:subClassOf ex:Party .
ex:Invoice  a owl:Class .

ex:legalName a owl:DatatypeProperty ;
    rdfs:domain ex:Customer .

ex:billedTo a owl:ObjectProperty ;
    rdfs:domain ex:Invoice ;
    rdfs:range  ex:Customer .

This declares three classes, a name attribute for customers and the relationship that links an invoice to the customer it bills. Reuse established ontologies where they fit. In finance, FIBO from the EDM Council provides OWL definitions for legal entities, contracts and financial instruments. In healthcare, coded data in FHIR resources typically points at terminologies such as SNOMED CT, which has more than 360,000 concepts. Taking the relevant slice of these saves you modelling definitions that experts have already agreed, and makes your data understandable to partners. The choice between a full ontology and a lighter taxonomy is covered in ontology vs taxonomy vs knowledge graph.

The mappings with R2RML

R2RML, a W3C Recommendation since September 2012, is the standard language for mapping relational data to RDF. A mapping is itself written in RDF, usually Turtle. Each triples map reads a table or SQL query, builds a subject IRI from a template, and attaches classes and properties.

Here is a mapping for the CRM's customer table:

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix ex: <https://data.example.com/ontology#> .

<#CrmCustomerMap> a rr:TriplesMap ;
    rr:logicalTable [ rr:tableName "crm_accounts" ] ;
    rr:subjectMap [
        rr:template "https://data.example.com/id/customer/{account_id}" ;
        rr:class ex:Customer
    ] ;
    rr:predicateObjectMap [
        rr:predicate ex:legalName ;
        rr:objectMap [ rr:column "company_name" ]
    ] .

And one for billing, which stores the CRM account ID in a column called crm_ref:

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix ex: <https://data.example.com/ontology#> .

<#InvoiceMap> a rr:TriplesMap ;
    rr:logicalTable [ rr:tableName "billing_invoices" ] ;
    rr:subjectMap [
        rr:template "https://data.example.com/id/invoice/{invoice_no}" ;
        rr:class ex:Invoice
    ] ;
    rr:predicateObjectMap [
        rr:predicate ex:billedTo ;
        rr:objectMap [ rr:template "https://data.example.com/id/customer/{crm_ref}" ]
    ] .

For a CRM row with account_id 4471 and company_name "Northwind Ltd", and an invoice row with invoice_no INV-0912 and crm_ref 4471, the two maps produce these triples:

<https://data.example.com/id/customer/4471> a ex:Customer ;
    ex:legalName "Northwind Ltd" .
<https://data.example.com/id/invoice/INV-0912> a ex:Invoice ;
    ex:billedTo <https://data.example.com/id/customer/4471> .

The integration happens in that last template. Both mappings produce the same customer IRI for the same account, so a query that follows ex:billedTo lands on the customer defined by the CRM. No join logic is written anywhere except in the shared identifier scheme.

The W3C also publishes a companion standard, Direct Mapping, that turns a database into RDF automatically. Its output mirrors table and column names exactly, so it is useful for exploration but not for integration. R2RML is what lets you target a shared ontology.

The query engine

With the ontology and mappings in place, a virtual knowledge graph engine such as Ontop accepts SPARQL and translates it into SQL against the sources. Ontop is open source under Apache 2.0, accepts R2RML as well as its own mapping syntax, and supports many databases, including PostgreSQL, SQL Server, Oracle, Snowflake, Databricks, BigQuery, Redshift and DuckDB, plus federation engines such as Trino and Dremio.

A business user, or an application, can now ask:

PREFIX ex: <https://data.example.com/ontology#>

SELECT ?name (COUNT(?inv) AS ?invoices)
WHERE {
  ?inv a ex:Invoice ;
       ex:billedTo ?c .
  ?c ex:legalName ?name .
}
GROUP BY ?name
ORDER BY DESC(?invoices)

The engine works out that ex:legalName comes from the CRM table and ex:billedTo from billing. Because both IRI templates are built from the same key, it can join on account_id = crm_ref in SQL rather than comparing IRI strings. Ontop sends its SQL over one database connection, so when the CRM and billing live in separate systems, a federation engine such as Trino, Dremio or Denodo sits underneath and runs the cross-system join. Ontop uses lightweight ontologies in the RDFS and OWL 2 QL range to enrich queries; for example, a query for ex:Party automatically includes customers, because ex:Customer is declared a subclass, and would include suppliers too once they are added the same way. The trade-offs between OWL profiles are explained in ontology languages: RDF, RDFS, OWL and SHACL.

Virtual knowledge graph or materialized graph?

R2RML mappings can be executed in two ways. You can run them virtually, translating each query to SQL at run time, or you can materialize them, running the mappings in batch to produce RDF triples that you load into a triple store.

| Factor | Virtual knowledge graph | Materialized knowledge graph | |---|---|---| | Data freshness | Always current | As fresh as the last load | | Storage | No copy of the data | Full copy in a triple store | | Query speed | Depends on source databases and SQL rewriting | Fast graph queries, independent of sources | | Reasoning | Limited to what rewriting supports (OWL 2 QL) | Richer reasoning on the stored graph | | Load on sources | Every query hits production systems | Only the batch extract does | | Operational cost | Mappings and an engine | ETL, a triple store and refresh jobs |

There is no single right answer; the choice depends on your workload, so benchmark your own queries before deciding. A common pattern is to start virtual, because it is cheap to prove value, then materialize the parts that need heavy graph traversal, reasoning, or isolation from busy source systems. The mappings stay the same either way, which is one of the real benefits of standardizing on R2RML.

Where the semantic layer fits

Analytics teams may recognize part of this picture from semantic layers. The dbt Semantic Layer, powered by MetricFlow, defines entities, dimensions and metrics once and serves them to BI and AI tools. In October 2025 dbt Labs open-sourced MetricFlow under Apache 2.0 and committed to the Open Semantic Interchange effort led by Snowflake.

A metrics layer and ontology-based data integration solve neighbouring problems. The metrics layer answers "how do we compute revenue?" consistently over a warehouse. The ontology answers "what is a customer, and how does it relate to contracts, invoices and tickets across every system?" A metrics layer has no formal logic or reasoning, and it usually assumes the data is already integrated in one warehouse. Many organizations will end up with both: the ontology defines the entities, and the metrics layer defines the numbers computed over them.

A rollout plan for ontology-based data integration

A common failure mode for ontology-based data integration is starting with a grand enterprise model. A narrower path works better:

Pick one cross-system question that people can't answer today, such as "which enterprise customers have overdue invoices and open priority-one tickets?"
Model only what that question needs. Customers, invoices, tickets, plans. Reuse FIBO or schema.org terms where they match.
Agree on identifiers. Decide how each source identifies a customer and how they line up. This is the entity resolution step, and it is usually the hardest part.
Write R2RML mappings for the relevant tables, one triples map per table.
Stand up a virtual knowledge graph with Ontop or a similar engine and answer the question with SPARQL.
Add SHACL checks on a materialized sample of the mapped output, or run the shapes as SPARQL queries against the endpoint, so broken mappings fail visibly.
Extend source by source. Each new system needs one set of mappings to the shared ontology, not a mapping to every other system.

Building and testing the ontology itself in code is covered in how to build an ontology in Python with RDFLib. The same Turtle files can feed Ontop directly.

FAIR data and research integration

In research settings, ontology-based integration is often driven by the FAIR principles, published in Scientific Data in 2016. Their interoperability principles ask that data and metadata use a formal, shared language for knowledge representation and vocabularies that are themselves FAIR. Mapping lab databases to shared ontologies such as the Gene Ontology is a form of ontology-based data integration that meets that requirement directly. Healthcare follows a similar pattern: FHIR records each coded value as a system URL plus a code, so a SNOMED CT concept is identified by the system http://snomed.info/sct and its concept ID.

Does ontology-based data integration replace ETL?

Not entirely. ETL and ELT pipelines move and reshape data so it can be stored, aggregated and served quickly. Ontology-based integration changes what those pipelines target. Instead of each pipeline inventing its own customer table, every source is mapped to the same ontology terms, and the integrated view is defined once.

In a virtual setup, a good share of ad hoc integration work disappears, because new cross-system questions can be answered with a SPARQL query rather than a new pipeline. Heavy aggregation over billions of rows still belongs in a warehouse or lakehouse, where columnar engines are built for it. In a materialized setup, the R2RML mappings are themselves a form of ETL, run on a schedule, but declarative and aimed at a shared model rather than hand-written per target table.

The realistic outcome is a hybrid. The warehouse keeps doing high-volume analytics. The ontology and its mappings define the shared entities and relationships, feed the warehouse's conformed dimensions, and power the cross-domain questions, APIs and AI applications that a star schema handles badly. Framing the work this way positions the ontology as an addition to the existing data platform, not a replacement for it.

Common pitfalls

No agreed identifiers. Mappings that produce different IRIs for the same customer give you two disconnected graphs. Settle the identifier scheme before writing mappings.
Over-modelling. Heavy OWL axioms that the query engine's profile ignores add effort and no value. Stay within RDFS and OWL 2 QL for virtual setups.
Ignoring source performance. A virtual knowledge graph query is only as fast as the slowest database it touches. Watch for queries that pull large tables across the network, and materialize where needed.
Licensing surprises. Some domain ontologies, notably SNOMED CT, have restrictive licence terms. Check them before you build on them.
Treating the ontology as a project deliverable. Business meaning changes, so the ontology and mappings need owners, versioning and review like any other code.
Confusing a metrics layer with an ontology. Both are useful; neither replaces the other.

Ontology-based data integration for AI applications

Integrated, well-typed data is exactly what AI systems need. An LLM application that answers questions about customers from a knowledge graph with consistent entities can cite specific entities and relationships instead of paraphrasing loosely related documents. The ontology gives the model a fixed vocabulary of entity types and relationships, and the virtual knowledge graph gives it current facts.

Two articles in this series pick up that thread. Ontologies and LLMs covers how a domain model grounds model answers and agent actions. Ontology-driven GraphRAG covers building a knowledge graph from documents with an LLM, using the ontology to keep entity types consistent, and combining that graph with the structured data integrated here.

Key takeaways

Ontology-based data integration maps every source to one shared ontology, so queries target business concepts instead of individual systems.
It has three parts: the ontology, the sources and the mappings; R2RML is the W3C standard for the mappings.
A virtual knowledge graph engine such as Ontop translates SPARQL to SQL and leaves data in place; materializing into a triple store trades freshness for speed and richer reasoning.
Shared identifiers are what actually connect the sources. Agree on them first.
A semantic or metrics layer complements an ontology but does not replace it.
Start with one cross-system question, model only what it needs, and extend source by source.

Ontology-Based Data Integration with Virtual Knowledge Graphs