Ontology-Based Data Access (OBDA)

The domain ontology is the central, unifying conceptual model in an OBDA system. It provides a shared, formal vocabulary of classes, properties, and axioms that describe the business domain (e.g., 'Customer', 'Product', 'purchases'). This ontology is typically expressed in a language like OWL 2 QL, a profile chosen for its balance of expressivity and efficient query answering. It serves as the single, high-level schema that users and applications query against, abstracting away the complexities of the underlying data sources.

Mappings are the critical bridge that connects the high-level ontology to the low-level data sources. They are declarative rules that specify how data in source schemas (e.g., relational tables, CSV columns, API fields) corresponds to instances and properties in the ontology. A mapping rule typically follows the pattern:

• Target: An ontological assertion (e.g., :Customer(?x)).
• Source: A query over the data source (e.g., SELECT cust_id FROM db.customers). These mappings enable the OBDA system to rewrite a SPARQL query over the ontology into a set of source-specific queries (like SQL).

This is the computational engine of the OBDA system. When a SPARQL query is posed against the ontology, the reasoner (or query rewriter) performs two key functions:

1. Ontological Reasoning: It expands the query using the ontology's axioms (e.g., subclass hierarchies). A query for :Vehicle will also retrieve instances of its subclass :Car.
2. Query Rewriting: It uses the mapping rules to transform the expanded ontological query into an equivalent union of conjunctive queries (UCQ) expressed in the vocabulary of the data sources. This resulting query, often in SQL, can be executed directly by the source databases.

OBDA is designed to integrate heterogeneous and legacy data sources without requiring migration. Supported sources typically include:

• Relational Databases (PostgreSQL, Oracle, MySQL)
• NoSQL Stores (MongoDB, Cassandra)
• CSV/JSON Files
• APIs and Web Services
• Other RDF Graphs Each source retains its native format and management system. The OBDA layer provides virtual, integrated access through the ontology, a key advantage over physical data warehousing.

This component refers to the strategy for handling instance data (ABox).

• Virtual ABox (On-Demand): The dominant OBDA approach. Instance data remains in the original sources. The system provides a virtual RDF graph; queries are rewritten and pushed down to the sources at runtime. This ensures access to live data with no duplication.
• Materialized ABox (Pre-computed): All instance data is extracted, transformed via mappings, and physically stored as RDF in a triplestore. This can improve query performance for complex patterns but introduces data latency and storage overhead.

The SPARQL endpoint is the standard access interface for the OBDA system, allowing applications to submit SPARQL queries as if querying a single, unified RDF knowledge graph. Internally, the system handles query federation: decomposing the single SPARQL query, rewriting sub-queries for different sources, executing them in parallel or sequence, and combining the results. Advanced OBDA systems optimize this process, considering source capabilities, network latency, and pushing down filters and joins where possible.

OBDA creates a virtual unified view over disparate, heterogeneous data sources—such as relational databases (SQL), NoSQL stores, CSV files, and APIs—without physically moving or replicating the data. A central conceptual ontology provides a consistent business vocabulary, while declarative mappings translate SPARQL queries into optimized source-specific queries (e.g., SQL). This enables real-time querying across the entire data landscape through a single semantic interface, decoupling business logic from underlying storage schemas.

• Key Benefit: Eliminates the latency and ETL complexity of building a physical data warehouse for exploratory queries.
• Example: Querying :Customer churn risk which requires joining customer records (PostgreSQL), support tickets (MongoDB), and usage logs (data lake).

OBDA systems streamline complex regulatory reporting (e.g., GDPR, BCBS 239, MiFID II) by providing a deterministic, auditable query layer. Regulations often define required data in conceptual terms (e.g., "transaction," "counterparty," "risk exposure"). An ontology formally encodes these concepts and their relationships. Compliance officers can write SPARQL queries aligned directly to regulatory requirements, and the OBDA engine automatically retrieves the correct data from siloed source systems, ensuring consistency and traceability.

• Key Benefit: Provides a single source of semantic truth for compliance, reducing manual reconciliation errors.
• Example: Generating a BCBS 239 "Single Customer View" report by querying the ontology for :Customer total exposure, pulling data from 10+ legacy banking systems.

OBDA acts as a non-invasive integration layer for legacy system modernization. Instead of costly, risky re-engineering of monolithic applications, an ontology is built to represent the desired future-state data model. Mappings are then created from the legacy system's often poorly documented schemas to this ontology. New applications and analytics are built to query the modern semantic layer, while the legacy systems continue to operate unchanged. This provides immediate business value and de-risks the modernization roadmap.

• Key Benefit: Unlocks data from legacy mainframe (COBOL/IMS) and ERP systems for modern analytics and APIs without modifying core systems.
• Technical Detail: Uses R2RML (RDB to RDF Mapping Language) or custom mapping dialects to define the transformation from relational tables to ontological classes and properties.

In biomedical research, OBDA is critical for integrating multiscale biological data. Researchers need to query across genomic databases (e.g., ClinVar), proteomic repositories, electronic health records (EHRs), and scientific literature. Domain ontologies like the Gene Ontology (GO) or SNOMED CT provide the unifying conceptual framework. An OBDA system allows a researcher to ask a complex question like "Find all genes associated with disease X that have known drug targets" in one query, with results automatically federated from specialized, remote databases.

• Key Benefit: Accelerates translational research by enabling complex, cross-domain queries impossible with traditional integration.
• Example: The Ontario Cancer Institute's OBDA system integrates clinical and genomic data for personalized oncology research.

OBDA provides real-time visibility into complex, multi-party supply chains. Data sources include IoT sensor streams (location, temperature), ERP inventory tables, carrier APIs, and weather feeds. A supply chain ontology models entities like :Shipment, :Container, :Route, and :DelayEvent. Logistics managers can query for "all perishable shipments at risk of delay due to port congestion," with the OBDA engine resolving the query across operational databases and live APIs. This enables proactive exception management and dynamic rerouting.

• Key Benefit: Moves from reactive tracking to predictive, semantic-aware supply chain intelligence.
• Technical Detail: Often combines static mapping for ERP data with virtual graphs that call REST APIs on-demand to incorporate real-time telemetry.

OBDA serves as the structured knowledge backbone for Retrieval-Augmented Generation (RAG) systems, moving beyond vector-only retrieval. The ontology defines a precise schema of enterprise entities and relationships. User queries in natural language are first interpreted against this ontology to generate a precise SPARQL query. This query retrieves deterministic, factual subgraphs from the underlying mapped data sources. These verified facts are then provided as context to a Large Language Model (LLM), drastically reducing hallucinations and providing citations to source systems.

• Key Benefit: Provides factual grounding for LLMs with traceability back to operational system of record.
• Architecture: Contrasts with vector search, which retrieves by semantic similarity but cannot guarantee factual correctness or execute complex joins.

The OBDA architecture presents a virtual RDF graph to the user. The data is not physically converted and stored as RDF triples in a triplestore. Instead, the combination of the ontology and the mappings creates a virtual, integrated view of all the connected data sources as if it were a single, queryable RDF knowledge graph. When a SPARQL query is executed, the engine on-the-fly retrieves and combines data from the underlying sources to materialize the relevant portion of this virtual graph for the query result. This avoids the cost and latency of full data materialization.

Query rewriting is the core computational task of an OBDA engine. It involves:

• Unfolding: Replacing ontology terms in the SPARQL query with their concrete definitions from the mappings.
• Source Selection: Determining which data sources are relevant for each part of the query.
• Translation: Generating efficient, native queries (e.g., optimized SQL) for each source. Query optimization is crucial for performance, as it must minimize data transfer and leverage source database indexes. Techniques include pushing filters and joins down to the source queries and merging queries to reduce the number of source calls.

An OBDA system maintains a registry or catalog of connected data sources. Each entry contains the technical connection details (JDBC URL, credentials) and metadata about the source's schema and capabilities. The mapping definitions reference these registered sources. This registry allows the OBDA system to manage a heterogeneous environment of sources—such as PostgreSQL, MySQL, Salesforce, and REST APIs—and dynamically generate the correct dialect of query for each one during the query rewriting phase.