Ontology mediation is the comprehensive process of resolving mismatches between different ontologies at query time or design time, encompassing ontology mapping, merging, and query rewriting to enable transparent data access across heterogeneous knowledge graphs. It acts as a middleware layer that translates concepts and data structures between incompatible semantic schemas, allowing a system to query multiple sources as if they were a single, coherent knowledge base without physically integrating the data.
Glossary
Ontology Mediation

What is Ontology Mediation?
Ontology mediation is the overarching process of resolving semantic and structural mismatches between heterogeneous ontologies to enable transparent, unified data access and interoperability.
The core challenge addressed by ontology mediation is semantic heterogeneity, where different ontologies model the same real-world domain using divergent terminologies, granularities, or axiomatizations. Mediation systems employ alignment algorithms to identify correspondences, then use these mappings to reformulate queries—transforming a query expressed in the terms of one ontology into equivalent queries against the schemas of others—ensuring complete and accurate result retrieval.
Key Characteristics of Ontology Mediation
Ontology mediation is the comprehensive process of enabling transparent, unified querying across multiple heterogeneous data sources by resolving semantic mismatches at either design time or query time. It encompasses the mapping, merging, and logical rewriting of distinct conceptual schemas.
Design-Time vs. Query-Time Resolution
Mediation strategies are categorized by when the semantic reconciliation occurs. Design-time mediation involves creating a static, global schema (a merged ontology) that all data sources are mapped to before any queries are executed. Query-time mediation uses a virtual approach, where user queries against a unified ontology are dynamically rewritten into source-specific sub-queries using declarative mappings, as seen in Ontology-Based Data Access (OBDA) systems.
The M3 Mapping Model
A foundational framework for classifying semantic mismatches that must be resolved during mediation. It identifies conflicts at three levels:
- Model Mismatches: Differences in modeling paradigms (e.g., relational vs. graph).
- Meta-Model Mismatches: Differences in schema constructs (e.g., class vs. property).
- Model-Instance Mismatches: Conflicts between the schema definition and the actual data population. Understanding these layers is critical for selecting the correct alignment and merging strategy.
Global-As-View (GAV) Approach
A query-time mediation strategy where the global unified ontology is defined as a view over the local data sources. Each class or property in the global schema is associated with an explicit query (e.g., in SPARQL or SQL) that specifies exactly how to retrieve its instances from the underlying sources. This approach simplifies query rewriting but can make adding new data sources difficult, as the global view must be manually updated.
Local-As-View (LAV) Approach
An alternative query-time strategy where each local data source is defined as a view over the global ontology. The mediation engine must perform complex reasoning to reformulate a global query into queries on these local views. While adding new sources is trivial (just describe the new view), query reformulation is computationally intensive. This is the foundational paradigm behind Ontology-Based Data Access (OBDA) using R2RML mappings.
Ontology Merging vs. Alignment
Mediation involves two distinct technical operations:
- Ontology Alignment: The process of identifying correspondences (mappings) between entities in different ontologies, typically using the Alignment API format to represent
owl:sameAsorrdfs:subClassOflinks. - Ontology Merging: The process of taking the source ontologies and the generated alignment to create a single, unified, and coherent ontology. This step often requires alignment repair to resolve logical inconsistencies introduced by the mappings.
Semantic Preserving Rewriting
The core computational challenge of query-time mediation. A user's SPARQL query, written against the global ontology's vocabulary, must be algorithmically rewritten into a union of queries against the physical schemas of the underlying data sources. This process must be semantically preserving, meaning the rewritten query must return exactly the same answers that the original query would if all data were materialized under the global ontology, a property verified through SPARQL entailment regimes.
Frequently Asked Questions
Clear, technical answers to the most common questions about resolving semantic mismatches between heterogeneous ontologies and knowledge graphs.
Ontology mediation is the overarching process of resolving semantic and structural mismatches between different ontologies to enable transparent, unified data access without physically merging the source models. It works by establishing a declarative mapping layer that defines correspondences between entities in the source ontologies, then using a mediation engine to rewrite or translate queries expressed in terms of a global schema into queries executable against the local schemas. Unlike static alignment, mediation can operate at query time (virtual integration) or design time (materialized merging). The core mechanism involves three phases: mismatch detection (identifying heterogeneities), correspondence specification (defining mappings using languages like the Alignment Format or R2RML), and query reformulation (transforming a SPARQL query over the mediated schema into equivalent queries over the underlying data sources). This approach preserves the autonomy of the original ontologies while providing a unified access point, making it essential for enterprise knowledge graph federation and ontology-based data access (OBDA) architectures.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts and mechanisms that enable the resolution of semantic mismatches between heterogeneous knowledge representations.
Ontology Alignment
The computational process of determining correspondences between heterogeneous ontologies to achieve semantic interoperability. Also known as ontology matching, it identifies equivalence, subsumption, and disjointness relations between entities. Modern systems combine lexical matchers, structural analyzers, and neural embedding models to generate candidate mappings with confidence scores.
Semantic Heterogeneity
The divergence in meaning or interpretation of data across different schemas, representing the primary obstacle to automated knowledge graph interlinking. Manifests in four forms:
- Terminological heterogeneity: Different names for the same concept
- Conceptual heterogeneity: Different modeling granularity or coverage
- Syntactic heterogeneity: Different representation formats
- Semiotic heterogeneity: Different interpretations by human communities
Alignment Repair
The post-matching process of detecting and removing incoherent correspondences from a generated alignment to restore logical satisfiability. When mappings introduce contradictions—such as violating the Conservativity Principle by creating unintended subclass relationships—repair algorithms prune the minimal set of correspondences needed to restore consistency while maximizing alignment coverage.
Ontology-Based Data Access
A virtual data integration paradigm that uses an ontology as a high-level conceptual schema to mediate queries across heterogeneous data sources. OBDA systems employ R2RML mappings to translate SPARQL queries into native SQL, enabling transparent access without physical data consolidation. The ontology serves as the mediated schema that users query, while the system handles reformulation to underlying sources.
Stable Marriage Problem
An algorithmic solution applied to ontology matching that finds a stable one-to-one mapping between two sets of entities based on mutual preference scores. Each entity ranks potential matches by similarity, and the algorithm produces a pairing where no two entities would prefer each other over their assigned partners. This optimizes global alignment cardinality and prevents conflicting one-to-many mappings.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us