Ontology-Compliant Knowledge Graphs

• Ontology-Compliant Knowledge Graphs are knowledge graphs where entities and relations are rigorously validated against an ontology, ensuring both semantic and structural alignment.
• They employ bidirectional harmonisation techniques that map KG elements to ontology commitments, using confidence scoring and matching strategies to improve consistency.
• Practical implementations include LLM-based pipelines and embedding models that enhance extraction quality and interoperability through structured, ontology-guided reengineering.

Searching arXiv for papers on ontology-compliant knowledge graphs and closely related ontology-grounded KG construction. Ontology-compliant knowledge graphs (OCKGs) are knowledge graphs whose entities, relations, and admissible structures are constrained, validated, or reengineered against an ontology rather than extracted as unconstrained triples. Across the literature, the idea appears under exact and adjacent labels—including ontology-compliant, ontology-grounded, ontology-aware, and ontology-based KGs—but the recurring objective is stable alignment between graph instances and ontology commitments such as canonical relation vocabularies, class/property usage, domain and range restrictions, disjointness axioms, provenance models, or deploy-time ontology fragments selected from real data (Qiang, 22 Mar 2026, Feng et al., 2024, Mihindukulasooriya et al., 2023). In its strongest formulations, compliance is bidirectional: the KG is brought into semantic conformity with the ontology, and the ontology is reshaped so that unused or mismatched terms do not dominate the deployed graph (Qiang, 22 Mar 2026).

1. Concept and intellectual lineage

The exact term ontology-compliant knowledge graph is explicitly developed as a bidirectional KG–ontology harmonisation paradigm in which compliance has both a semantic and a structural dimension. One formulation defines OCKGs through two compatibility conditions: semantic/terminological compliance, where mismatched KG terms are replaced or mapped to relevant ontology classes and properties, and coverage compliance, where the ontology is reconstructed to reflect what is actually used in the KG (Qiang, 22 Mar 2026). A related lifecycle-oriented formulation presents OCKGs as a pay-as-you-go approach for discovering the most cost-effective ontology fragment that fits given KG(s), positioning them as the deploy-phase mechanism in a broader ontology interoperability ecosystem that also includes ontology design patterns and ontology matching/versioning (Qiang, 16 Jul 2025).

Adjacent research traditions reach comparable goals through different vocabularies. Ontology-grounded LLM pipelines restrict KG construction to an authored ontology aligned with Wikidata properties and OWL/RDF output constraints (Feng et al., 2024). Ontology-driven extraction benchmarks define compliance operationally as extracting facts from text while obeying a supplied ontology’s concepts, canonical relations, and domain/range constraints (Mihindukulasooriya et al., 2023). Earlier conceptual work argues for an ontologically grounded and language-agnostic canonical representation in which abstract objects are reified, everything is strongly typed, and only a fixed set of primitive relations is admitted (Saba, 2023).

A broader theoretical backdrop is provided by the ontological continuum, which treats KG engineering as movement through a connected space structured by two orthogonal distinctions: semantics vs pragmatics and properties vs affordances. In that framework, ontology alignment is not only a matter of vocabulary matching but of whether a KG affords what a given community needs for a given task, expressed as $$\text{affords}(\text{KG}, \text{community}, \text{task})$$ (Daga et al., 21 May 2026). This suggests that OCKGs are best understood not as a single fixed architecture but as a family of ontology-governed graph engineering strategies.

Formulation	Core compliance idea	Representative sources
OCKG	Bidirectional KG–ontology harmonisation	(Qiang, 22 Mar 2026)
Ontology-grounded KG	KG generation restricted by authored ontology and Wikidata schema	(Feng et al., 2024)
Ontology-driven KG generation	Text extraction must obey ontology relations and typing guidance	(Mihindukulasooriya et al., 2023)
Ontologically grounded KG	Reified abstract objects and fixed primitive relations	(Saba, 2023)

2. What “compliance” means

Compliance is not uniform across the literature. In the most explicit OCKG account, internal compliance concerns ontology compliance within a single KG–ontology pair, whereas external compliance concerns ontology compliance over multiple KGs and ontologies for matching, alignment, and harmonisation (Qiang, 22 Mar 2026). Internal compliance includes detecting KG terms and ontology classes/properties, matching them with confidence, and reconstructing an ontology that keeps relevant classes, properties, triples, constraints, and axioms. External compliance uses those internally compliant representations as a bridge for cross-KG matching.

A second, more operational view treats compliance as satisfaction of ontology-level semantic constraints. In an automatic ontology generation framework, a raw text-derived KG is refined by anomaly exclusion, disjointness checking, KG completion, and alignment to domain ontologies so that the final output respects class membership, disjointness axioms, and domain/range restrictions (Elnagar et al., 2022). The same work introduces the temporary ontology-like object OKG, computes inconsistency $\epsilon$, and describes the final output as $domainOnT = OKG - \epsilon$ (Elnagar et al., 2022). In this sense, compliance means that graph content survives only if it fits the target ontology.

LLM-based ontology-grounded KG construction under the Wikidata schema defines compliance more narrowly but more concretely. Competency questions determine scope, extracted relations are matched to Wikidata properties, the resulting ontology includes schema:description, rdfs:domain, and rdfs:range, and KG generation is explicitly constrained by the instruction: “Do not include new properties other than those in ontology. Only use those properties in the ontology” (Feng et al., 2024). Text2KGBench adopts a related operational definition: a generated triple is ontology-conforming if it uses the ontology’s canonical relation names, with the benchmark designed to separate fact extraction quality, ontology conformance, and hallucination control (Mihindukulasooriya et al., 2023).

Other domains extend compliance beyond class/property matching. For industrial standards, compliance is split into structural compliance, where documents are mapped into an explicit hierarchy, and logical compliance, where sentences and tables are decomposed into atomic propositions under a controlled predicate set (Park et al., 9 Dec 2025). For interoperable simulation data, compliance includes ontology-aligned normalization, explicit provenance via PROV-O, and validated RDF generation through ontology-mirrored data models rather than ad hoc triple creation (Guzman et al., 31 Mar 2026). These variants differ in formalism, but all treat the ontology as a constraint on what counts as an admissible graph.

3. Construction and reengineering pipelines

A recurrent construction pattern is extract → validate → complete → align. In one domain-independent framework, text is first cleaned, then converted into a preliminary KG by a generator such as Neo4j or Watson, with confidence scores attached to extracted entities and relations (Elnagar et al., 2022). Refinement then removes irrelevant nodes, illogical nodes, low-confidence relations, disconnected concepts, and implausible facts. The framework applies the rule that if confidence score is < 0.3 the concept or relation is removed, and if confidence score is between 0.3 and 0.5 then Local Outlier Factor (LOF) is applied (Elnagar et al., 2022). Correctness checking uses association rule mining, disjointness axioms, first-order logic, and reference ontology validation with YAGO and DOLCE. Missing links are then inferred by embedding-based KG completion; the implemented scoring function is the ComplEx form

$$f_r(h,t)=\Re\left(h^T \operatorname{diag}(r)\overline{t}\right)$$

before the refined KG is aligned to a target domain ontology (Elnagar et al., 2022).

LLM-based pipelines replace part of this symbolic refinement stack with schema-guided generation. Under the Wikidata schema, one four-stage pipeline performs Competency Question-Answer Generation, Relation Extraction and Ontology Matching, Ontology Formatting, and KG Construction (Feng et al., 2024). Relations extracted from competency questions are matched to candidate Wikidata properties through sentence embeddings and LLM vetting; the embedding model used for property usage comments is bge-small-en (Feng et al., 2024). The authored ontology is then serialized as OWL, and final KG generation is restricted to ontology-approved properties. A related RAG-oriented study compares ontology-guided KGs built from RDB-derived ontologies and text-derived ontologies, using modified RIGOR for the former, DINGO as reference ontology, Turtle (TTL) as ontology format, and lists of allowed classes and relations as the effective compliance layer during instantiation (Cruz et al., 8 Nov 2025).

Reengineering-oriented OCKG workflows emphasize term matching and ontology reconstruction. The algorithm for “Building Ontology Compliance within KG” extracts concept and relation sets from the KG, class and property sets from the ontology, and applies a progression of pure matching, heuristic matching, semantic matching, and topological matching, with a total confidence score computed from the individual match confidences (Qiang, 22 Mar 2026). The reconstruction phase finds superclasses and superproperties of matched terms and rebuilds a reshaped ontology from the related triples. The companion algorithm for “Building Ontology Compliance over KGs” first makes each KG internally compliant, then matches across the reconstructed ontologies, and finally uses X2Vec.train() embeddings to retrieve overlapping terms (Qiang, 22 Mar 2026).

Pattern-based compliance introduces a more modular view. Instead of forcing one monolithic ontology, ontologies are decomposed into fragments or patterns—illustrated in the building domain by Brick Schema fragments for spaces, equipment/systems, and points—and these are mapped to near-equivalent fragments from ontologies such as BOT, SAREF, SSN/SOSA, RealEstateCore, or Project Haystack (Qiang, 22 Mar 2026). This suggests that some OCKG workflows are not about one ontology governing one graph, but about selecting and combining interoperable ontology fragments under explicit criteria.

4. Formal models and representational commitments

The strongest formal account of ontology compliance in embeddings rejects the assumption that standard KG completion models are automatically compatible with ontological reasoning. A geometric framework models each relation symbol $R$ as a region $\eta(R)\subseteq \mathbb{R}^{k\cdot m}$ and each object $o$ as a vector $\eta(o)\in\mathbb{R}^m$, with a ground atom satisfied exactly when the concatenation of argument vectors lies inside the relation region (Gutiérrez-Basulto et al., 2018). In this framework, ontology-compliant embeddings should induce facts that are both logically consistent and deductively closed with respect to the ontology. The same analysis shows that translation-based models such as TransE and TransR, bilinear models such as DistMult and ComplEx, and even SimplE fail on basic rule patterns, whereas ontologies expressed using quasi-chained existential rules can be exactly represented using convex regions (Gutiérrez-Basulto et al., 2018).

A different formal commitment appears in ontologically grounded, language-agnostic KG design. There, the key move is to reify abstract objects—events, properties, states, tropes—and distinguish concepts from types, so that a role-like notion such as “teacher” is not treated as a primitive type in the same way as “human” (Saba, 2023). The representation is restricted to a fixed set of primitive relations including eq, isPartOf, inst, hasProp, exemp, dep, isA, precedes, participantIn, hasAgent, hasObject, hasValue, and realizes (Saba, 2023). In that setting, compliance is achieved not by post hoc validation alone but by a canonical representational discipline that excludes ad hoc predicate proliferation.

The ontological continuum adds another layer of formalization through Formal Concept Analysis (FCA). KGs are characterized by semantic properties, semantic affordances, pragmatic properties, and pragmatic affordances; a binary feature matrix over KGs and attributes is then projected into concept lattices that order KGs by richness of characterization profiles (Daga et al., 21 May 2026). This is not a compliance checker in the narrow sense, but it supplies a formal vocabulary for comparing and transforming KGs along dimensions that matter for ontology-governed reuse.

5. Evaluation regimes and benchmark evidence

Benchmarking OCKGs has developed along two main lines: direct extraction benchmarks and downstream task evaluations. Text2KGBench is designed specifically for ontology-driven KG generation from text. It provides two datasets: Wikidata-TekGen with 10 ontologies and 13,474 sentences and DBpedia-WebNLG with 19 ontologies and 4,860 sentences, and defines seven evaluation metrics spanning fact extraction, ontology conformance, and hallucinations (Mihindukulasooriya et al., 2023). On Wikidata-TekGen, average results for Vicuna-13B were P 0.38, R 0.34, F1 0.35, OC 0.83 on the full set; on DBpedia-WebNLG the same model achieved P 0.34, R 0.27, F1 0.30, OC 0.93 (Mihindukulasooriya et al., 2023). The benchmark’s importance lies in showing that high ontology conformance can coexist with only moderate fact extraction quality.

Ontology-grounded LLM construction under Wikidata has been evaluated on Wiki-NRE, SciERC, and WebNLG using partial F1 on KG triplets (Feng et al., 2024). The reported results for the proposed method with Mistral-7B-Instruct are 0.66 / 0.60 on Wiki-NRE, 0.73 / 0.58 on SciERC, and 0.74 / 0.68 on WebNLG, where the paired numbers correspond to target-schema constrained and no schema constraint settings; GPT-4o reaches 0.71, 0.77, and 0.76 in the constrained setting (Feng et al., 2024). The constrained setting systematically favors benchmark-aligned evaluation, while the unconstrained setting exposes the tension between ontology discovery and gold-schema scoring.

The exact OCKG paper evaluates both internal and external compliance. For internal compliance, the reported table shows the progression from the Original ontology with used entity 0.52%, matching rate 46.15%, confidence 100% to Lv. 4 reshaping with used entity 46.15%, matching rate 92.31%, confidence 78.33% (Qiang, 22 Mar 2026). For over-compliance, embedding-based matching is evaluated with DeepWalk, node2vec, and struc2vec, and the compliance-aware pipeline outperforms traditional KG embedding without ontology compliance in almost all reported top-$k$ settings (Qiang, 22 Mar 2026). This evidences a trade-off: more permissive matching improves coverage but can lower confidence.

Downstream evaluations further indicate that ontology guidance alone is not always sufficient. In a RAG comparison over a real-world grant application, GraphRAG, Text Ontology KG + chunks, and RDB Ontology KG + chunks each achieved 18/20 correct answers (90%), while Vector RAG achieved 12/20 correct (60%), Text Ontology KG without chunks only 15% accuracy (3/20), and RDB Ontology KG without chunks 20% accuracy (4/20) (Cruz et al., 8 Nov 2025). This suggests that ontology compliance is especially effective when combined with chunk-level textual evidence rather than used as a purely schema-level abstraction.

6. Domain-specific implementations

OCKGs have been implemented in domains where interoperability, provenance, and schema drift are operationally consequential. In atomistic simulation data, an ontology-based infrastructure combines the Computational Materials Sample Ontology (CMSO) and the Atomistic Simulation Methods Ontology (ASMO) with PROV-O, QUDT, and MDO to normalize heterogeneous records into an ontology-aligned RDF representation (Guzman et al., 31 Mar 2026). The resulting KG contains 757,253 RDF triples describing 7,926 computational samples and supports querying, workflow traceability, partial reconstruction, and derived-property computation such as the volumetric thermal expansion coefficient $\alpha = \frac{1}{V}\frac{\partial V}{\partial T}$ (Guzman et al., 31 Mar 2026). Validation includes competency questions, integration-driven querying, the Ontology Pitfall Scanner, and OWL reasoners such as HermiT (Guzman et al., 31 Mar 2026).

In high-performance computing operational data analytics, a unified ontology models telemetry from the M100 and F-DATA datasets within a single semantic layer (Khan et al., 8 Jul 2025). The ontology has 12 classes, 23 object properties, 25 data properties, and 164 axioms, and is validated through 36 competency questions across topology, sensor monitoring, job metrics, user activity, scheduling, and cross-system comparison (Khan et al., 8 Jul 2025). The paper reports a reduction in KG storage overhead from 1074.89 MiB to 657.36 MiB, with an additional reduction to 481.00 MiB when SensorReading is represented as blank nodes, corresponding to 38.84% reduction relative to the previous ontology and 26.82% additional reduction in the blank-node configuration (Khan et al., 8 Jul 2025). Here compliance is inseparable from deployment constraints such as storage and telemetry scale.

In systems engineering workflows, ontology compliance is realized through OML vocabularies, OWL conversion, and RDF materialization of workflow models, artefacts, and process traces (Ryś et al., 10 Dec 2025). The architecture uses hand-written meta-model vocabularies, an adaptor service, Fuseki, a workflow enactment engine, and a draw.io frontend. The KG is ontology-compliant because descriptions must conform to their vocabularies, inconsistency in OML-to-OWL conversion causes failure, and SHACL can be used for additional constraints (Ryś et al., 10 Dec 2025). A drivetrain smart sensor case study reports that the framework reduced effort around storage, versioning, access to relevant information, and inferred knowledge (Ryś et al., 10 Dec 2025).

Industrial standards provide a different compliance profile. A hierarchical and propositional ontology-based KG framework models document structure as

$\epsilon$0

and decomposes rules and tables into atomic propositions under a restricted relation vocabulary such as has_condition_AND and has_consequence_OR (Park et al., 9 Dec 2025). On the IndusSpec-QA evaluation, the paper reports average F1 of 0.454 for ontology-aware KG-RAG, compared with 0.304 for conventional KG-RAG, 0.277 for text-only RAG, and 0.016 for LLM-only baselines; for toxic clause detection, ontology-aware KG-Retriever reaches F1 0.910, Accuracy 0.913, and Recall 0.926 (Park et al., 9 Dec 2025). In this setting, compliance is closely tied to preserving hierarchy and logical structure rather than merely to relation normalization.

7. Limitations, tensions, and open directions

Several tensions recur across the literature. First, ontology compliance is difficult to scale because ontology alignment itself remains labor-intensive. The ontology interoperability ecosystem states explicitly that OCKGs require extensive workload to find alignments between different ontologies, and the payoff of compliance often depends on an iterative loop between deploy-time observations and redesign (Qiang, 16 Jul 2025). Second, common embedding models do not, in general, support ontology-compliant learning: the region-based analysis shows that popular translation and bilinear models cannot encode even simple ontological dependencies, so completion quality should not be conflated with logical compatibility (Gutiérrez-Basulto et al., 2018).

Third, the source of the ontology matters. Text-derived ontologies can drift, accumulate redundancy, and require ontology merging as new documents arrive, whereas RDB-derived ontologies inherit the relative stability of database schemas and can make ontology learning a one-time-only process (Cruz et al., 8 Nov 2025). LLM-based ontology-grounded construction also has explicit cost and robustness issues: one study notes about three LLM calls per document plus one call per extracted relation, and identifies long-context difficulty as a remaining limitation (Feng et al., 2024). Earlier automatic ontology generation work is conceptually useful but provides no standard quantitative evaluation such as precision, recall, F1, Hits@K, MRR, or accuracy (Elnagar et al., 2022).

A further limitation is that many deployed OCKGs remain domain-bounded and partially curated. In atomistic simulation data, legacy datasets often lack complete metadata, some external dependencies are not yet fully represented in structured form, complete workflow reconstruction remains limited, and scalability to very large or continuously changing datasets is still to be demonstrated (Guzman et al., 31 Mar 2026). For industrial standards, ontology compliance is enforced through structural and lexical controls rather than full OWL-style logical validation (Park et al., 9 Dec 2025). More generally, the ontological continuum identifies five open challenges: formalising the dimensions of characterization, formalising dependencies across the continuum, enabling modular context-aware reuse, supporting co-evolution of interdependent artefacts, and developing human-in-the-loop strategies grounded in explainable GenAI assistance (Daga et al., 21 May 2026).

Taken together, these results indicate that OCKGs are not merely ontology-decorated graphs. They are an engineering and modeling stance in which graph construction, reconstruction, matching, retrieval, and sometimes vector representation are subordinated to ontology commitments that are explicit enough to improve interoperability and constrained enough to expose mismatches. The main unresolved question is not whether ontology compliance is useful, but how strongly it should be enforced, at what level of formalism, and with what trade-off between expressiveness, cost, and deploy-time fitness for a community and task.