Ontology-Based Data Access

OBDA separates concerns into three distinct layers:

• Ontology Layer: A high-level conceptual schema defining business entities and relationships using OWL 2 QL
• Mapping Layer: Declarative R2RML or custom mappings that connect ontological terms to relational schemas
• Data Layer: Existing relational databases that remain untouched and in-place

This separation allows domain experts to query using familiar business concepts while databases remain optimized for operational performance.

The core mechanism of OBDA is query rewriting. When a user submits a SPARQL query against the ontology, the OBDA engine:

• Parses the SPARQL graph patterns
• Consults the mapping assertions to identify relevant database tables and columns
• Reformulates the query into one or more native SQL queries
• Executes against the actual relational database
• Transforms SQL result sets back into RDF triples

This process is transparent to the end user, who never sees the underlying SQL.

OBDA systems typically use the OWL 2 QL profile, a fragment of the Web Ontology Language specifically designed for efficient query answering over large datasets. Key properties:

• Enables query rewriting to first-order SQL without requiring a separate reasoner at query time
• Captures common modeling constructs: class hierarchies, disjointness, domain/range constraints
• Sacrifices some expressivity (no existential quantification on right-hand side of subsumptions) for polynomial-time query answering
• Implemented by engines like Ontop and Stardog

OBDA creates a virtual knowledge graph—an RDF representation that appears to exist but is never physically materialized. Benefits include:

• Zero ETL: No batch extraction, transformation, or loading processes required
• Real-time access: Queries always reflect the current state of the source database
• Reduced storage costs: No duplicate data infrastructure
• Simplified governance: Source systems remain the single source of truth

The virtual graph is defined entirely through declarative mappings, not data copying.

Mappings are the critical bridge between ontology and data. Each mapping assertion defines:

• A source: SQL query over one or more relational tables
• A target: RDF triple pattern using ontology terms

Example mapping logic:

• Map SELECT id, name FROM employees to ex:Employee instances with foaf:name properties
• Join employees.department_id to departments.id to generate ex:worksFor relationships

These mappings are typically authored using R2RML or vendor-specific DSLs with graphical editors.

OBDA is the foundational paradigm for integrating heterogeneous clinical and genomic data. Institutions use the Observational Medical Outcomes Partnership (OMOP) Common Data Model as an ontology to virtualize patient records, drug exposures, and lab results stored across disparate hospital systems.

• Query Translation: SPARQL queries over the OMOP vocabulary are reformulated via R2RML mappings into SQL for each source database.
• Use Case: Enables cross-institutional cohort identification for rare disease research without moving protected health information.
• Reasoning: OWL 2 QL ontologies allow for class subsumption reasoning at query time, expanding a search for 'Cardiovascular Agent' to automatically include all mapped subclasses like beta-blockers and ACE inhibitors.

Energy companies deploy OBDA to unify petrotechnical data locked in legacy PPDM (Professional Petroleum Data Management) relational databases and real-time drilling sensors. An upper-level ontology defines concepts like 'Wellbore', 'Formation', and 'Seismic Survey'.

• Semantic Mediation: A geologist queries for 'all wells penetrating the Brent Group formation' using a conceptual vocabulary, while the OBDA engine rewrites this into complex SQL joins across well headers, directional surveys, and stratigraphic tables.
• Temporal Reasoning: The ontology captures the 4D nature of reservoirs, allowing queries about the state of a well at a specific geological time or operational phase.

Museums and archives use OBDA to expose heterogeneous cataloging systems as a unified Linked Data endpoint. The CIDOC Conceptual Reference Model (CRM) ontology serves as the global schema, mediating between native MARC, Dublin Core, or relational collection management systems.

• Event-Centric Modeling: CIDOC-CRM models historical events (e.g., the 'Production of a Sculpture') as central entities linking actors, places, dates, and objects. OBDA mappings transform flat relational records into this rich event graph.
• Query Example: A researcher can query for 'all objects created in Florence during the Medici era' across multiple institutions' databases via a single SPARQL endpoint, with the OBDA system handling the syntactic and semantic translation to each source.

Factories implement OBDA to create a virtual knowledge graph over operational technology (OT) data silos. An ontology based on ISA-95 standards defines the hierarchy of equipment, materials, and processes.

• Real-Time Access: OBDA mappings connect the ontology directly to time-series databases and MES (Manufacturing Execution System) tables. A query for 'all sensors on Line 7 reporting temperature > 80°C in the last hour' is rewritten into a SQL window function query against the historian.
• Predictive Maintenance: Maintenance ontologies define failure modes and their observable symptoms. OBDA allows a diagnostic query to traverse from a 'Pump Cavitation' event class to the specific vibration sensor readings and material batch IDs stored in separate SCADA and ERP systems.

Intelligence agencies use OBDA to fuse geospatial intelligence (GEOINT) from imagery databases, signals intelligence (SIGINT) logs, and human intelligence (HUMINT) reports without centralizing classified data. A spatio-temporal ontology defines entities like 'Facility', 'Event', and 'Person'.

• Geospatial Query Rewriting: The ontology includes OGC GeoSPARQL topological relations (e.g., sf:within, sf:intersects). An OBDA engine translates a SPARQL query for 'all observation posts within 5km of a known border crossing' into SQL with PostGIS spatial functions on the underlying relational tables.
• Provenance Tracking: The ontology captures the source and confidence of each assertion. OBDA mappings ensure that query results include the lineage of the data, allowing analysts to trace a geospatial relationship back to the original SIGINT intercept.

Financial institutions deploy OBDA to enforce a business glossary over their data landscape. An ontology defines authoritative terms like 'Customer', 'Trade', and 'Risk Exposure', mapped via OBDA to their physical representations in hundreds of source systems.

• Data Lineage at Query Time: When a compliance officer queries for 'all trades by a politically exposed person (PEP)', the OBDA system uses the ontology's definitions and mappings to identify the relevant tables and columns across trading, KYC, and watchlist databases.
• Policy Enforcement: The ontology can encode regulatory rules (e.g., GDPR residency restrictions). The OBDA query rewriting process can inject additional SQL filters based on these rules, ensuring that a query automatically excludes data from customers in restricted jurisdictions without the analyst needing to know the physical data location.