How classifying being
became a knowledge engine

Overview

Ontology (ontos, being + logos, study) asks "what exists, and how is it classified and related?" This site traces the 2,300-year lineage of that question as it moved from philosophy through engineering into AI — and collects the theory, architecture, and learning route needed to build it into a knowledge service.

• Philosophy sets down the principles of classifying being — categories, essence, ontological commitment.
• Engineering hardens those classifications into logic (OWL · DL) and proves them at scale in biomedicine.
• AI reverses the direction — LLMs build ontologies, and ontologies constrain LLMs.

The one-line engineering conclusion: make every write pass schema validation, and make every read return its evidence path.

Theoretical Foundations

Quine's insight — "what a theory commits itself to can be read off the range of values of its variables" — translates perfectly into engineering language. The set of entity types a system references, stores, and reasons over is that system's ontology.

The three schools of foundational ontology

Selection guidance: experiment- and observation-centric → BFO; language- and document-centric → DOLCE; domain-model coherence matters most → UFO. The common practice is a hybrid: align only the top 5–10% to a foundational ontology and design the domain layer yourself.

Translating philosophical concepts into engineering

The representation stack and its seven functions

The stack builds from application → generation (LLM) → reasoning (DL reasoners · SHACL) → representation (OWL 2/RDF) → storage (graph + vector). OWL 2 profile trade-offs: EL for large-scale classification, RL for rule execution, QL for querying, and full DL reserved for offline validation.

1. Reasoning — hierarchy derivation, consistency checking, instance classification
2. Alignment & matching — linking heterogeneous ontologies
3. Embedding — reasoner-aware vectorization such as OWL2Vec*
4. Validation — OOPS! design-flaw scanning + SHACL data validation
5. Evolution — versioning and backward compatibility
6. Construction automation — LLM-based extraction of terms, relations, axioms
7. Joint retrieval — using the ontology to structure the search space

LLMs × Ontologies

Three turns in the lineage: bake knowledge into the model → let LLMs build ontologies → let ontologies constrain LLMs.

1. Knowledge injection (2017–2021)

K-BERT injected triples into the sentence tree and used attention masks to block the false positives of knowledge overload. KEPLER bound MLM and knowledge-embedding loss into a single pre-training objective. QA-GNN reasoned over query-relevant subgraphs with a GNN and fused the result with the language model. Limitation — updates required retraining, and that limitation pushed the paradigm toward externalizing the graph: GraphRAG.

2. LLMs build ontologies (2023–2026)

LLMs4OL (2023) reformulated the four tasks of ontology learning — term extraction, type classification, taxonomy discovery, relation discovery — as LLM tasks. By 2025, three-stage agent pipelines (generate → refine → populate; product KGs with 97% attribute coverage reported) and human-in-the-loop verification had become standard practice. The working principle: the LLM is a proposer, not an architect. Schema commits must pass foundational-alignment and human review — direct empirical comparisons between LLM-generated and expert-built ontologies are still missing.

3. Ontologies constrain LLMs (2024–2026)

"Can KGs reduce LLM hallucinations?" (2024 survey) systematically reviewed the hypothesis; OG-RAG (2025) interpreted queries as ontology entities and relations, then delivered only evidence-grounded context; Conversational Control (2026) used ontologies as a lightweight constraint frame and demonstrated explainable output control. BIM code compliance and CVE assessment show "compliance-oriented generation" becoming a pattern.

The mutual reinforcement loop

The loop's trustworthiness scales with the strength of the normalization and validation stage. The dashed (vermilion) path is user feedback re-entering as proposals.

GraphRAG × Ontologies

Graph paths repair vector RAG's multi-hop failures, retrieval drift, and missing evidence. The ontology gives retrieval a grammar.

Four ontology-grounded patterns

GraphRAG without an ontology degenerates into schema-free graph search. Evaluation axes — multi-hop accuracy, faithfulness, citation precision, robustness under attack and noise.

Knowledge Engines

The storage and query layer. Vector-graph hybrids are converging on a standard.

• Unified engines: AkasicDB (2026) — vector-graph-relational in one. TigerVector (2025) — vector search inside a graph DB.
• Co-optimization: RAG-Stack (2025) — retrieval quality and storage performance designed as one system.
• Query: the Cypher family; LLM-based query generation (Auto-Cypher).
• Security: retrieval pivot attacks — graph paths become the attack surface. Path trust and provenance enforcement required.

Deploying reasoners

Full DL reasoning (HermiT-class) is too expensive for online use. Working deployment: schema validation and classification run as offline batches; online serves materialization (pre-computed inference graphs) plus lightweight SHACL validation; rules are pushed down into the graph engine.

Integrated Architecture

The six-layer skeleton of an ontology-based knowledge service, and the knowledge lifecycle.

● ink: application  ● vermilion: AI · generation  ● jade: knowledge · engineering — same palette as the hero timeline's eras.

Technology choices

The knowledge lifecycle

Eight stages form a closed loop — evolution leads back to extraction (the dashed path in the loop diagram above).

Service API skeleton

Build Roadmap

Five stages from taxonomy to an evolution loop. Each stage's exit criterion is the gate.

Five evaluation axes

• Ontology quality — pitfall count (OOPS), DL consistency violations, alignment rate, axiom density
• KG quality — extraction precision/recall, entity-resolution accuracy, freshness
• Retrieval — hit@k, MRR, multi-hop accuracy
• Generation — faithfulness, citation precision, hallucination rate
• Operations — schema backward-compatibility rate, gate pass rate, p95 latency

Five risks

1. Schema rigidity — keep the foundational layer thin, split constraints out into SHACL
2. LLM ontology quality gap — human gate mandatory, ongoing sampled audits
3. Reasoning cost explosion — EL/RL online, DL offline
4. Graph attack surface — path trust, provenance enforcement
5. Hybrid complexity — single engine first, coherence tests for the fusion layer

Open Problems

Nine research gaps were logged in the initial survey (216 papers) — follow-up collection closed eight of them (425 papers today). Below: what was filled, and the one problem that genuinely remains.

Closed — evidence per gap

Click a paper button to open its details and source links. The full closure ledger is in research report v2.

Remaining gap — genuinely open

Rigorous empirical comparison of LLM-generated ontologies vs. expert foundational ontologies (0.9) — research on the quality and evaluation of LLM-built ontologies has grown, but direct comparisons of coverage, consistency, and philosophical validity against BFO/UFO/DOLCE alignment remain scarce. Until the trust boundary of construction automation can be quantified, operators must bridge the gap with human gates and their own sampled audits (Risk 2, chapter VII). Kept as a follow-up research topic.

Learning Route

Five stages — from philosophy's question to building architect. Click any representative paper to open its details.