Is Your “Ontology Product” Just an Advanced Intelligent Query Engine?

1. Why It Must Be a “Reasonable Ontology”

Gruber’s 1993 definition states that an ontology is an explicit, formal specification of a domain. The key word is “formal”: the specification must be encoded in a language with logical interpretation, such as OWL 2 DL or an equivalent custom logical framework, not merely in documentation, white‑board ER diagrams, or JSON‑Schema field types.

Only with formal semantics can machines perform logical inference, such as understanding that a “publicly listed company” is a subclass of “organization”, detecting that an age of –5 violates a data‑type constraint, or spotting contradictory ownership chains.

These tasks are not query optimisation; they are logical deductions that require an independent, controllable external reasoning engine .

Because large language models (LLMs) rely on statistical emergence and cannot guarantee 100 % logical certainty, a deterministic reasoning program is needed to produce provably correct judgments.

The core division of labor is therefore: the LLM generates text, while the ontology’s reasoning engine validates and decides.

2. Nine‑Dimensional Acceptance: Is Your Product an Ontology or an Intelligent Query System?

If a product claims to “reduce hallucinations with a large model”, it must satisfy all nine dimensions below; missing any one means it is essentially an intelligent query system.

First Layer – Semantic Foundations (No foundation, no building)

1. Formal Semantic Layer : The schema must be encoded in a logical language that supports class inclusion (⊑), property constraints (∀, ∃), cardinality limits (≥, ≤, =), disjoint classes, transitive properties, etc. Criterion: Is the schema expressed in OWL or a comparable logical language, rather than simple property‑graph tags?

2. T‑Box / A‑Box Constraint Configuration : T‑Box defines what can be said (class axioms, property chains, key constraints, disjointness). A‑Box validates whether statements are correct (instance property types, cardinality violations, uniqueness). Criterion: Can the system automatically detect contradictions and reject invalid writes instead of merely showing an alert?

Second Layer – Reasoning Core (Without it, the ontology is just a fancy vocabulary)

3. Reasonable Inference Engine : The engine must run outside the LLM as a controllable program, supporting concept inclusion inference, instance classification, consistency checking, and property closure computation. Criterion: Does the engine use a sound and complete reasoner such as HermiT, Pellet, or FaCT++, or a self‑built rule engine with published soundness/completeness metrics?

4. Explainable Generation (NLG) : The engine must output a proof tree that can be translated into structured Chinese (or English) for the LLM to consume. Example:

“Rejection reason: The ontology axiom requires ‘publicly listed company’ to be a subclass of ‘organization’ and to have a ‘stock code’ attribute. The current instance lacks this attribute, violating the cardinality constraint.”

Criterion: When the LLM receives a rejection, does it also receive a semantic explanation rather than just an error code?

Third Layer – Interaction Adaptation (Determines whether the product can serve the LLM)

5. System Integration Capability : The ontology must expose standard interfaces (SPARQL endpoint or REST API) to consume real‑time A‑Box updates and push inference results downstream. Criterion: Can the reasoning engine incrementally update inference results when external data changes, without full recomputation?

6. Scenario‑Specific Semantic Adaptation : Different domains (e.g., medical diagnosis vs. financial risk) should load distinct semantic modules. An input router maps LLM queries to the appropriate semantic space, and the engine loads the corresponding axiom set. Criterion: Does the system support “one base, many semantics” instead of rewriting the schema for each scenario?

7. Data Lifecycle Management : Ontology data must carry provenance and verification status. The lifecycle follows:

Pending verification (LLM‑generated) → Reasoning check → [Approved] Verified → [Failed] Contradiction pool → Human arbitration

Criterion: Does each triple carry source tags and timestamps, and does the system support version rollback?

Fourth Layer – Engineering Realisation (Determines scalability)

8. Rapid Iterative Elastic Updates : The T‑Box must support hot‑updates without interrupting the reasoning service. Adding classes or properties must not break existing A‑Box consistency, and impact analysis is required. Criterion: After modifying a class axiom, does the system need to shut down and rebuild?

9. Quick Configuration : A visual ontology editor should allow drag‑and‑drop class creation, constraint configuration, and inference testing. Criterion: Can a non‑technical business user complete basic T‑Box configuration within 30 minutes?

3. Self‑Check Checklist

The following list summarises the nine dimensions and the expected behaviour of a qualified ontology product versus an intelligent query system.

Formal Semantic Layer : JSON‑Schema / property‑graph tags vs. OWL 2 DL or equivalent logical framework.

Contradiction Detection : No automatic detection (or hand‑written if‑else) vs. reasoning engine automatically rejects contradictions.

Reasoning Engine : Absent or pseudo‑rule engine vs. description‑logic based decision program.

Explainable Generation : Returns error code only vs. returns structured Chinese (or English) explanation.

System Integration : Supports only queries vs. supports incremental updates and closed‑loop push.

Scenario Adaptation : One schema for all vs. modular semantics with routing.

Data Lifecycle : Stateless management vs. verification → contradiction pool workflow.

Hot Update : Requires downtime vs. online impact analysis.

Configuration Barrier : Requires developer hard‑coding vs. business user can configure in 30 minutes.

If any of the first three items (formal semantics, reasoning engine, constraint configuration) are missing, the product is fundamentally an intelligent query system, regardless of how many times “ontology” appears in presentations.

4. Final Thoughts

Domestic tech giants excel at engineering, productisation, and cost control. Knowledge graphs solve many data‑governance problems, and large models have produced competitive products. However, “ontology” is a rigorously defined technical concept. Mislabeling ER diagrams as ontologies, rule engines as reasoning machines, or prompt engineering as world models harms the industry’s technical honesty.

In an era where LLM hallucination is a core pain point, a genuine ontology product must act as a “logical gate”: the LLM generates, the ontology decides; the LLM explores, the ontology validates.

Without formal semantics and an external reasoning engine, a so‑called ontology is merely a well‑packaged intelligent query system, which cannot cure LLM hallucination because it is part of the hallucination itself.