Deciphering the Mysteries of Noumenon: From Aristotle to Large Language Models, A 2,000-Year-Spanning Knowledge Revolution

Opening Guide

The pace of technological iteration has never been so rapid. Artificial intelligence has stood at the peak of the wave, pressing the accelerator for technological innovation and pushing the entire era toward a brand-new intelligent future.

From 2023 to 2026, Palantir's stock price surged 32 times.

The reason is straightforward: over 20 years, this company focused on one single goal — pushing the concept of "Ontology" to its absolute pinnacle. Using ontology, it weaves scattered data across various enterprise systems into a unified "Digital Twin", enabling machines not only to "see" data but also to "understand" the relationships between data points and make autonomous decisions accordingly.

But what exactly is "Ontology"? It is not a newly emerged concept. From the era of ancient Greek philosopher Aristotle, to the Semantic Web vision proposed by World Wide Web inventor Tim Berners-Lee, to the knowledge graphs in today's large language model era — the secret of ontology is a knowledge revolution spanning two thousand years.

Today we will break it down step by step: Where does the history of ontology originate? What are its core components? How to build it? What tools to use? And — what is its connection with today's most popular large language models?

01

What is Ontology? — From "Being" to "Knowledge Model"

In the ancient Academy of Athens before the Common Era, Aristotle raised a question: "Among all things in the world, how many fundamental modes of existence are there?" He put forward the earliest systematic classification, dividing "being" into ten categories in total: Substance, Quantity, Quality, Relation, Place, Time, Posture, State, Action, and Affection.

This marks the origin of "Ontology" — a discipline concerning "being". In Greek, "Onto-" means "being", and "-logy" means "doctrine". The questions that ontology aims to answer are: What exists in this world? How do these things exist? What relationships do they share with each other?

More than two thousand years later in 1993, Tom Gruber from Stanford University proposed a definition applicable to computer scientists — "Ontology is an explicit, formal specification of a shared conceptualization". While this phrase sounds somewhat convoluted, it becomes very easy to understand when broken down:

Shared — Not a random idea from an individual, but a consensus reached by the team

Conceptualization — Not a simple list of terms, but a relational network connecting all concepts

Explicit — Every element is clearly defined with no ambiguous areas

Formal — Readable, computable, and inferable by machines

To put it more plainly: Ontology is "a knowledge model that enables machines to understand how things in the world are categorized and related to each other". It is like a panoramic map of the business world, marking all critical entities (Classes), their respective features (Properties), the connections between entities (Relations), and the non-negotiable bottom lines that must not be violated in business operations (Axioms/Rules).

02

Millennium Evolution: Four Transformations of Ontology

Looking back at the developmental history of ontology, four distinct stages can be clearly identified:

Stage 1: The Philosophical Era (300 BCE — 1950s)

Ontology served as a speculative tool in the hands of philosophers, used to explore the ultimate question of "what exists in the world". From Aristotle's ten categories to Kant's distinction between phenomena and noumena, ontology has always been the core battlefield of metaphysics. It addressed purely philosophical questions and had no connection whatsoever with computer science.

Stage 2: The AI Knowledge Engineering Era (1980s — 2000s)

The turning point arrived with the rise of artificial intelligence. Researchers discovered that to make machines intelligent, the first step is to let them understand "what exists in the world". In the 1980s, Doug Lenat launched the Cyc project, which attempted to encode all human common sense into machine-readable rules. To this day, it remains one of the largest manually constructed ontologies. In 1998, the Gene Ontology was born, becoming the most critical knowledge infrastructure in the biomedical field.

Stage 3: The Semantic Web Era (2000 — 2012)

In 2001, World Wide Web inventor Tim Berners-Lee envisioned the "Semantic Web" — using ontologies to add "machine-understandable semantic labels" to data across the internet. Subsequently, RDF (2004), OWL (2004), and SPARQL (2008) successively became W3C standards. However, the ideal was grand while the reality was harsh: the extremely high cost of ontology construction, insufficient reasoning performance, and the lack of killer applications prevented the ambitious Semantic Web vision from being widely implemented on a large scale.

Stage 4: The Knowledge Graph and AI-Native Era (2012 — Present)

In 2012, Google launched its Knowledge Graph. This time, ontologies no longer pursued the unrealistic goal of "adding semantics to the entire internet", but instead focused on solving practical problems. Palantir transformed ontology into a "Digital Twin Operating System" for enterprises, driving its stock price to surge 32 times. Unisound Technology proposed the "Ontology Neural Network (ONN)" paradigm, deeply integrating ontologies with large AI models. Ontology finally evolved from an academic concept into a tangible, high-value infrastructure for the industry.

03

Four Core Components of Ontology

A complete ontology is built from four foundational "building blocks":

Block 1: Class — Describing "Who/What"

A Class represents the core entities within a specific domain. In the contract management domain, you would define Classes such as Customer, Product, Contract, and Invoice. In an enterprise ontology, you would define Classes like Device, Sensor, and Employee. Each Class is a fundamental "building block" of the world modeled in the system.

Block 2: Property — Describing "What It Is Like"

A Property describes the characteristics of an entity. A Data Property connects an entity to a specific value — for example, a contract name is a string, the contract amount is a numeric value, and the signing date is a date type. An Object Property describes the relationship between two entity instances — such as "Contract → belongs to → Customer", "Device → is equipped with → Sensor". The former defines "what the entity is", while the latter defines "what it is related to".

Block 3: Relation — Describing "How Entities Are Connected"

In ontologies, relations are first-class citizens, not secondary attachments to database foreign keys. They carry inherent semantic meaning:

Customer --places--> Contract, Contract --contains--> Product, Factory --hosts--> ProductionLine

More importantly, OWL supports inverse properties: once you define the property "hasPaymentTerm" (from Contract to Payment Term), the reasoner can automatically infer the inverse property "belongsToContract" (from Payment Term to Contract). This would require writing complex JOIN operations in traditional databases, but it is automatically available in OWL.

Block 4: Axiom — Describing "What Can Be Done and What Cannot Be Done"

Axioms are the most powerful part of an ontology — they do not store raw data, but store rules. For example:

• Integrity Constraints

Each contract must have exactly one associated customer (cardinality constraint)

• Business Rules

If the total received payment for a contract is greater than or equal to the total contract amount, it is automatically classified as a "Completed Contract" (SWRL rule)

• Alert Logic

If the temperature of a device exceeds the threshold and this condition persists for more than 5 minutes, an "Overheating" alert is automatically generated

Traditional databases can only query "what you have stored", while an ontology paired with a reasoner can infer "what else you should know". This is the fundamental distinction between ontologies and traditional data models.

04

How to Build an Ontology? — The Seven-Step Method and Full-Stack Toolchain

Building an ontology is far more complex than writing a few lines of code; it is a systematic engineering process. Currently, the most widely recognized mature methodology in the industry is the "Seven-Step Ontology Construction Method" proposed by Stanford University:

Step

Tasks to Complete

Deliverables

1. Define the domain and scope

Who will use this ontology? What problems will it solve?

Requirements Specification Document

2. Reuse existing ontologies

Are there any pre-existing ontologies that can be directly used or adapted?

Ontology Reuse List

3. List all critical terms

What are the core terminologies in this domain?

Terminology Inventory

4. Define Classes and their hierarchical structure

How to group these terms? What is the inheritance relationship between them?

Class Hierarchy Tree

5. Define Properties

What characteristics does each Class have? How are different Classes related to each other?

Property Definition Table

6. Define constraints and rules

What operations are prohibited? What conditions will trigger specific consequences?

SWRL Rule Set

7. Create instances

Populate the model with real data to verify its correctness

Test Dataset

With a clear methodology in place, a full-stack toolchain is required to implement it:

📐 Modeling: Protégé (open-sourced by Stanford University, supports OWL 2, and can directly connect to reasoning engines)

🧠 Reasoning: HermiT / Pellet (description logic reasoners that automatically verify consistency and infer new facts)

🔍 Query: DL Query (a description logic-based query language for ontology-level reasoning and querying)

📜 Rules: SWRL (an IF-THEN rule language that expresses complex conditional reasoning that cannot be directly represented by OWL)

🗺️ Visualization: WebVOWL (renders OWL files into interactive class relationship diagrams)

💾 Storage and Query: GraphDB / Jena + SPARQL (graph database paired with a standard query language)

Let's dive deeper into Protégé — it is currently the most mainstream open-source ontology editor. Using it, you can intuitively create Classes, define hierarchical structures, attach Properties, write SWRL rules, connect to reasoners, and export OWL files. It also supports importing demonstration ontologies from URLs — for example, the built-in "Pizza Ontology" model, which new users can directly open to learn the basics.

A key practical tip: You do not need to manually write OWL XML code. By using a large language model paired with a carefully designed Prompt, you can directly generate a complete OWL definition file. Clearly describe your business requirements, and the large model will output a full ontology code that conforms to OWL semantic annotation standards — which can be imported directly into Protégé for use. This reduces the barrier to ontology construction by more than an order of magnitude.

05

How Are Ontologies Used? — Three Practical Case Studies

Case 1: Palantir × Global Automotive Supply Chain

A world-leading automotive manufacturer operates more than 20 factories across multiple countries, with data for materials, components, and production lines scattered across dozens of heterogeneous systems. The traditional approach of building data warehouses, writing ETL pipelines, and generating wide tables cannot capture the truly intelligent elements — the relationships between data points, business rules, and the predefined responses to potential problems — which remain invisible in these flat wide tables.

Palantir's solution: Build the ontology first, then connect to the data. On the Foundry platform, a complete supply chain ontology is defined: materials, factories, production lines, orders, and quality events are all formalized as Classes; the relationships between entities (Factory --has--> ProductionLine, Order --consumes--> Material) are all explicitly defined; critical rules (trigger automatic procurement when inventory falls below the safety threshold, generate production halt alerts for severe quality events) are all encoded as Axioms.

Results: Inventory turnover time reduced by 25%, supply chain response time shortened from 3 days to 8 hours, and cross-factory material allocation efficiency improved by 45%.

Case 2: Unisound Technology × Smart Healthcare

Unisound Technology built a healthcare operation system using the "Ontology Neural Network (ONN)" paradigm. The core ontologies include Patient, Doctor, Medication, and Medical Device. Key axioms include "If a patient is diagnosed with hypertension and is allergic to the active ingredient of the prescribed medication, trigger a contraindication alert", and "If a medical device has malfunctioned more than 2 times in the past 3 months and is currently in use, mark its risk level as High".

When a doctor asks "What is the medication status of hypertension patients admitted to the outpatient department recently?", the system does not simply query the database. Instead, multiple AI Agents work collaboratively: the condition filtering Agent performs semantic mapping, the field extraction Agent retrieves data from multi-source databases, the computation Agent executes reasoning based on ontology axioms, the quality inspection Agent conducts double-blind verification, and finally generates a structured report containing medication plans and personalized recommendations. This is no longer simple "data querying", but true "intelligent decision-making".

Case 3: Data Governance in the Financial Industry

Data governance in the financial industry has long faced a persistent dilemma: within the same bank, the credit card department, personal loan department, and wealth management department have completely different definitions of "Customer". The credit card department focuses on consumption behavior and credit scores, the personal loan department focuses on income and collateral, and the wealth management department focuses on risk preference and asset allocation. The data team attempted to build a unified "360-Degree Customer View", only to discover that the problem was not technical, but rooted in semantic inconsistency.

The ontology-based solution does not force the three different definitions into one, but instead constructs an upper-level ontology Schema — where "Customer" is a general term, and Credit Card Customer, Loan Customer, and Wealth Management Customer are three subclasses. These subclasses share a set of core properties (name, ID number) while retaining their own exclusive properties (credit limit, collateral, risk preference). Data no longer needs to be mutually "translated", but is organized properly under the unified ontology framework. Ontology solves the most costly problem in this era: semantic interoperability.

06

New Paradigm: LLM + Vector Database + Ontology = Neuro-Symbolic AI

At this point, you might ask: In the era of large language models, do we still need ontologies? ChatGPT seemingly knows everything — why bother with manual modeling?

The answer is: On the contrary — in the large language model era, ontologies are more critical than ever.

Large language models have four inherent weaknesses, which are precisely the areas where ontologies excel the most:

Hallucinations

— Large language models can confidently generate false information, while ontologies use axiom constraints to ensure output consistency

Outdated Knowledge

— The knowledge of large language models is frozen at their training cutoff date, while ontologies can be connected to the latest real-time enterprise data

Complex Reasoning Errors

— Multi-step reasoning by large language models is prone to mistakes, while dedicated reasoners (such as Pellet) can execute logical chains with perfect precision

Lack of Interpretability

— Large language models are black boxes, while ontologies provide transparent, symbolic reasoning paths that can be fully traced

A new architecture that is gaining widespread consensus is the collaborative operation of the "three carriages