Ontology-Based Data Access (OBDA)

The global ontology is a formal, domain-specific conceptual model that provides a unified vocabulary for querying. It defines the classes, properties, and relationships relevant to the business domain (e.g., Customer, Product, purchases). This ontology acts as the single, integrated schema that users and applications query against, insulating them from the complexity and heterogeneity of the source data structures. It is typically authored in a language like OWL 2 QL, a profile chosen for OBDA due to its favorable computational properties for query rewriting.

Data sources are the underlying, heterogeneous repositories where the actual instance data resides. These are typically relational databases (e.g., PostgreSQL, Oracle), but can also include CSV files, XML documents, or REST APIs. In an OBDA architecture, these sources remain in their native formats and locations; they are not physically integrated or replicated into a central warehouse. This preserves existing investments, governance, and performance characteristics while enabling virtual integration through the ontology layer.

Mapping assertions are the critical bridge that defines how the concepts in the global ontology relate to the schemas of the data sources. They specify how to populate ontology classes and properties with data from source tables, columns, and joins. Mappings are expressed in a declarative language (e.g., R2RML, Ontop's native mapping syntax) and follow a pattern:

• Class Mapping: :Customer is populated from rows in a CUSTOMERS table.
• Property Mapping: :purchases links a customer ID to an order ID via a SQL join between CUSTOMERS and ORDERS tables. These mappings enable the system to rewrite ontological queries into source-specific queries.

The OBDA engine is the core software component that processes queries. It performs two key functions:

• Query Rewriting: It takes a user's query expressed in terms of the ontology (e.g., a SPARQL query) and uses the mapping rules to rewrite it into a union of SQL queries (or other target query languages) executable against the original data sources.
• Reasoning: It performs limited ontological reasoning (e.g., exploiting subclass hierarchies defined in the ontology) during the rewriting phase to ensure all relevant data is retrieved. For example, a query for :Vehicle will also retrieve data mapped to its subclass :Car. Engines like Ontop and Mastro are specialized for this task.

The query interface is the access point for users and applications. In OBDA systems, this is most commonly a SPARQL endpoint—a standardized HTTP service that accepts queries in the SPARQL language. Users formulate queries using the vocabulary of the global ontology, without any knowledge of the underlying source schemas or SQL. The OBDA engine intercepts these SPARQL queries, rewrites them, executes the resulting source queries, and returns the unified results in a standard SPARQL results format (e.g., JSON). This provides a virtual RDF graph view of all connected data.

The Virtual ABox (or Virtual RDF Graph) is the logical layer presented to the user. It is the set of all instance data (ABox assertions) that appears to exist as a single, queryable RDF graph. This graph is not materialized; it is generated on-the-fly by the OBDA engine through the mapping definitions. When a SPARQL query is executed, the engine dynamically retrieves data from the sources and presents it as if it were a native RDF knowledge base. This virtual approach avoids the massive ETL overhead of physical integration while providing the same unified query capability.

OBDA systems streamline complex regulatory reporting (e.g., Basel III, GDPR, MiFID II) by providing a single, authoritative conceptual model for risk and customer data scattered across legacy systems. Competency questions like "Show all transactions for customer X involving high-risk jurisdictions in the last quarter" can be expressed in the ontology's terms. The OBDA engine uses mappings to rewrite this into queries against the underlying transaction databases, CRM, and KYC systems, automating report generation and ensuring consistency. This reduces manual reconciliation and audit preparation time from weeks to days.

Enterprises use OBDA to create a holistic customer profile without physically migrating data from siloed sources. A domain ontology defines concepts like Customer, Product, SupportTicket, and Purchase. R2RML mappings link these to tables in the CRM (Salesforce), support desk (Zendesk), and e-commerce database. A business analyst can then query for "customers who purchased product Y, opened a high-priority ticket within 30 days, but did not receive a follow-up call." The OBDA query rewriting process federates queries across the live source systems, presenting a virtual, integrated view that powers personalized marketing and proactive customer service.

During mergers and acquisitions, OBDA accelerates the integration of disparate IT landscapes. Instead of a costly, multi-year ETL project to create a single physical data warehouse, companies deploy a global ontology that abstracts the core business entities of both organizations. Ontology alignment techniques create mappings between each company's legacy schemas and this new unified model. This allows for immediate cross-company reporting and analysis (e.g., comparing supply chain performance or product portfolios) through semantic queries, providing business value during the critical post-merger integration phase while a longer-term technical consolidation proceeds.

OBDA provides real-time, contextual visibility across complex supply chains involving multiple ERPs (SAP, Oracle), warehouse management systems, IoT sensor streams, and partner data. An upper ontology for Event, Location, and Material is extended with a domain ontology for logistics. SPARQL queries ask "Find all shipments containing component A that are delayed due to a port closure and identify alternative suppliers within 500km of the destination." The OBDA system reasons over the ontology, understands the relationships between delays, locations, and parts, and retrieves answers from the mapped sources, enabling dynamic rerouting and risk mitigation.

In healthcare and pharma, OBDA enables federated querying over heterogeneous clinical databases, genomic repositories (like dbGaP), and published literature, all while respecting data sovereignty. A rich biomedical ontology (e.g., SNOMED CT, HPO) serves as the global schema. Researchers can pose complex queries such as "Find patients diagnosed with condition C, who have genetic variant V, and were prescribed drug D, along with reported outcomes from clinical trials." The OBDA engine, operating under a federated learning-like privacy paradigm, executes sub-queries against each authorized source, returning aggregated, anonymized results that accelerate cohort discovery and translational research without moving sensitive patient data.

OBDA acts as a deterministic grounding layer for Retrieval-Augmented Generation (RAG) architectures. Instead of a vector database retrieving potentially hallucinated text chunks, the knowledge graph populated via OBDA provides verified facts and relationships. A user asks a natural language question, which is translated into a SPARQL query over the enterprise ontology. The OBDA system retrieves precise, structured answers from the underlying mapped data sources. This context, rich with entities and their formal relationships, is then passed to the LLM for synthesis, ensuring the generated response is factually accurate and traceable back to source systems, dramatically reducing hallucinations.

An ontology is a formal, explicit specification of a shared conceptualization. It defines the classes (concepts), properties (relationships and attributes), and constraints (rules) that exist for a particular domain. In OBDA, the ontology provides the unified, high-level vocabulary over which users write queries, abstracting away the underlying data source schemas.

• Purpose: Serves as the global schema in an OBDA system.
• Example: A manufacturing ontology defines classes like Machine, ProductionOrder, and properties like hasStatus and produces.

A mapping is a set of declarative rules that define how the data in source databases (e.g., relational tables) corresponds to the concepts and relationships in the ontology. The W3C standard R2RML (RDB to RDF Mapping Language) is commonly used for this purpose.

• Function: Translates a SPARQL query over the ontology into a series of SQL queries over the source databases.
• Key Element: A mapping rule typically specifies how a database table row becomes an RDF instance (subject), how a column value becomes a property (predicate), and how that value is typed or linked (object).

A Virtual Knowledge Graph is the architectural result of an OBDA system. It presents a unified, queryable RDF graph view of the underlying data without physically materializing and storing all the triples. The graph is 'virtual' because it is generated on-the-fly via the mappings when a query is executed.

• Benefit: Eliminates data duplication and synchronization issues.
• Contrast: Differs from a materialized knowledge graph, where all RDF triples are pre-computed and stored in a triplestore.

SPARQL is the standardized query language for RDF graphs. In an OBDA system, end-users and applications submit SPARQL queries written using the terms from the ontology. The OBDA engine uses the mappings to rewrite this SPARQL query into one or more SQL queries executable against the source databases.

• Core Construct: The SELECT query retrieves data, while CONSTRUCT builds new RDF graphs.
• Pattern Matching: Queries use graph patterns (triple patterns) to find matching sub-graphs in the virtual knowledge graph.

Description Logic is the family of formal knowledge representation languages that provide the logical foundation for ontology languages like OWL. The expressivity of the chosen DL (e.g., OWL 2 QL) directly determines the query rewriting capabilities and computational complexity of the OBDA system.

• Role: Defines the formal semantics for ontology axioms (e.g., SubClassOf, EquivalentTo).
• OBDA Profile: OWL 2 QL is specifically designed for OBDA, enabling efficient query rewriting to SQL.

An ontology reasoner (or inference engine) is software that performs automated logical deduction over an ontology. In OBDA, the reasoner is used during system setup and query planning to classify the ontology hierarchy and ensure its consistency. This enriched logical model is used by the query rewriter.

• Pre-query Task: Computes the complete subsumption hierarchy (e.g., if Car is a subclass of Vehicle, a query for Vehicle will also return instances of Car).
• Critical Check: Performs consistency checking to ensure the ontology and mappings do not create logical contradictions.