跳轉到

為知識圖譜建構本體論是一個過程，而非一張圖

文章資訊

作者：Konrad Kaliciński　　日期：2026-06-16

原文標題：Building an Ontology for a Knowledge Graph Is a Process, Not a Diagram

Medium 原連結：https://akkonrad.medium.com/building-an-ontology-for-a-knowledge-graph-is-a-process-not-a-diagram-b30efb8cc632

🎧 摘要語音

📝 重點摘要

TL;DR

本體論不是一次畫完的圖，而是需持續演化維護的工程過程。

核心問題

選定 POLE+O 等基礎實體類型只是建模的第一步。文章探討：在那之後，該如何決定何者為節點、何者為屬性、何時形式化關係，以及當領域變動時模型如何存活——並把 30 年被忽視的本體論工程方法論翻譯成開發者語言。

關鍵發現 / 數據

  • Uschold & King（1995）提出三種至今仍是基礎的建模策略：top-down、bottom-up、middle-out；POLE+O 屬 middle-out。
  • 2024 研究將「能力問題」（competency questions）分為五類：scoping、validating、foundational、relationship、metaproperty。
  • 建議啟動時先寫 10–15 個能力問題，再碰任何建模工具。
  • 2026 AnIML 論文提出「對抗式負向能力問題」，用 SHACL 約束防止圖譜給出危險的錯誤答案。
  • 本體論審查排程建議：前六個月每月一次，之後每季一次。

方法亮點

  • 能力問題同時界定範圍、揭露隱藏關係、並提供驗收測試。
  • 本體論設計模式（ODP）：Participation、Sequence、Classification 等可重用模組（eXtreme Design）。
  • 本體論漂移（ontology drift）：模型悄悄與領域脫節，查詢仍可跑但結果失真，需如程式碼般版本化與審查。
  • 不是每個圖都需要形式化本體論——僅在跨系統互通、推論、跨團隊共識三者之一成立時才值得成本。

對我的研究有用嗎？

對 GraphRAG 研究頗有參考價值：能力問題可作為 schema 自動生成與評估的基準，Pan et al.（2024）已探索用 RAG-LLM 自動生成能力問題；「對抗式負向問題 + SHACL」概念可遷移到 LLM 抽取結果的約束驗證；本體論漂移則對應 KG 維護與時序建模議題。middle-out + 設計模式的取捨討論對自動化 schema 發現也有啟發。

評語

值得一讀的高品質實務綜述，論點扎實且引用真實文獻；但部分 2026 年論文（如 arXiv:2604.x、2606.x）編號可疑，引用前宜查證。

🌐 中英對照

Author: Konrad Kaliciński
Published:
Source: https://akkonrad.medium.com/building-an-ontology-for-a-knowledge-graph-is-a-process-not-a-diagram-b30efb8cc632
Fetched: 2026-06-16T10:23:08.940164

Building an Ontology for a Knowledge Graph Is a Process, Not a Diagram / 為知識圖譜建立本體論是一個過程，而非一張圖

Five established approaches, and the ongoing process that keeps them working.

五種既有的方法，以及讓它們持續發揮作用的那個持續性過程。

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整尺寸的圖片

generated with GPT

由 GPT 生成

Why I wrote this / 我為何撰寫本文

My recent article on POLE+O — the five-type ontology from Neo4j’s Create Context Graph — resonated more than the other articles around knowledge graphs. Also had a nice conversation in the knowledge graphs domain about ontologies and how to build them. So the natural follow-up question is: “OK, what comes after the five types?”

我最近一篇關於 POLE+O——源自 Neo4j《Create Context Graph》的五類型本體論 (Ontology)——的文章，比我其他關於知識圖譜 (Knowledge Graph) 的文章引起了更多迴響。我也在知識圖譜領域針對本體論以及如何建構它們進行了一場很好的對話。因此自然而然的後續問題是：「好，那麼在這五種類型之後又是什麼？」

Fair question. POLE+O gives you a starting anchor for entity classification. But picking base types is one decision in a process that has dozens more. How do you decide what becomes a node versus a property? When do you formalize relationships? What happens when the domain shifts and your model doesn’t?

這是個合理的問題。POLE+O 為實體分類 (entity classification) 提供了一個起始的錨點。但挑選基礎類型只是一個過程中眾多決策裡的其中一個，後面還有數十個決策。你如何決定什麼該成為一個節點 (node)，而什麼又該成為一個屬性 (property)？你何時該把關係 (relationship) 形式化？當領域改變了，而你的模型卻沒有跟著變時，又會發生什麼？

I went looking for answers in ontology engineering literature — a field with 30 years of published methodology that most KG practitioners never encounter. It is not obscure; it just lives in academic papers that nobody translates into developer language.

我前往本體論工程 (ontology engineering) 的文獻中尋找答案——這是一個擁有三十年已發表方法論的領域，但大多數知識圖譜實務工作者卻從未接觸過。它並不冷僻；它只是棲身於那些沒有人把它翻譯成開發者語言的學術論文之中。

This is my attempt at that translation.

這就是我嘗試進行的那種翻譯。

Three starting strategies / 三種起始策略

In 1995, Mike Uschold and Martin King published what’s considered the first explicit methodology for building ontologies. They defined three identification strategies — top-down, bottom-up, and middle-out — that still form the foundation of ontology engineering today.

1995 年，Mike Uschold 與 Martin King 發表了被認為是第一套明確的本體論建構方法論。他們定義了三種識別策略——由上而下 (top-down)、由下而上 (bottom-up) 以及由中間向外擴展 (middle-out)——時至今日，這三者仍構成本體論工程的基礎。

Top-down means beginning from the most abstract, general concepts and specializing downward. You start with categories like “Agent,” “Process,” “Artifact”, and refine them: Agent becomes Person and Organization, Process becomes Event and Transaction. Upper ontologies like BFO (Basic Formal Ontology) and DOLCE follow this path. The approach works well when you need cross-system interoperability and have the time and expertise to think in abstractions before writing a single query. The trade-off is exactly what you’d expect: teams that start top-down often produce rigorous, well-reasoned schemas that the project never actually uses because it ran out of patience two months in.

由上而下意指從最抽象、最一般性的概念開始，然後向下特化。你從像「行為者 (Agent)」、「流程 (Process)」、「人造物 (Artifact)」這樣的類別出發，再加以細化：行為者變成「人 (Person)」與「組織 (Organization)」，流程變成「事件 (Event)」與「交易 (Transaction)」。像 BFO（基本形式本體論，Basic Formal Ontology）和 DOLCE 這樣的上層本體論 (upper ontologies) 便遵循這條路徑。當你需要跨系統互通性 (interoperability)，並且擁有時間與專業知識，能在寫下任何一條查詢之前就先以抽象方式思考時，這種做法效果很好。其取捨正如你所預期的：採取由上而下起步的團隊，常常產出嚴謹、推理周密的綱要 (schema)，但專案卻從未真正使用它，因為它在進行了兩個月後就已耗盡耐心。

Bottom-up is the opposite. You start from actual data — spreadsheets, API responses, database dumps — and extract patterns. “These columns look like people. These rows are events. This foreign key is clearly a relationship.” You generalize from instances to classes. This is the natural approach for developers because it feels productive immediately. The trade-off: the model mirrors the shape of whatever data source you started with, including its biases and structural quirks. If your first dataset was an HR database, the ontology thinks the world is made of employees, departments, and leave requests. Uschold and King noted this problem in 1995. It’s still one of the most commonly reported failure modes in KG projects.

由下而上則相反。你從實際的資料——試算表、API 回應、資料庫匯出檔——開始，並萃取出模式。「這些欄位看起來像人。這些列是事件。這個外鍵 (foreign key) 顯然是一種關係。」你從實例 (instances) 概括出類別 (classes)。對開發者而言這是最自然的做法，因為它讓人立刻感到很有生產力。其取捨在於：模型會映照出你一開始所採用的那個資料來源的形狀，包括它的偏誤與結構性怪癖。如果你的第一個資料集是一個人力資源 (HR) 資料庫，那麼這個本體論就會以為世界是由員工、部門和請假申請所構成的。Uschold 與 King 在 1995 年就指出了這個問題。它至今仍是知識圖譜專案中最常被回報的失敗模式之一。

With middle-out, you begin from the most obvious concepts in the domain — the ones everyone on the team can point to — and expand in both directions. Generalize upward (what broader categories do these belong to?) and specialize downward (what subtypes exist?). POLE+O is a middle-out approach: five entity types that most domains recognize instantly, with domain-specific labels layered on top. I covered this in detail in a previous article. The strength is speed — you get a queryable graph fast. The risk is plateauing at “good enough” and never deepening the model past the initial categories.

採取由中間向外擴展時，你從領域中最顯而易見的概念——團隊中每個人都能指出來的那些——開始，並朝兩個方向展開。向上概括（這些屬於哪些更廣泛的類別？）以及向下特化（存在哪些子類型？）。POLE+O 就是一種由中間向外擴展的做法：五種大多數領域都能立即辨認的實體類型，再於其上疊加特定領域的標籤 (labels)。我在先前的一篇文章中詳細談過這一點。它的優勢在於速度——你能很快得到一個可查詢的圖譜。風險則在於停滯於「夠好就好」的高原期，而從未把模型深化到超越最初的那些類別。

None of these is universally right. Top-down when you need interoperability and can invest the time. Bottom-up when you need something running this week and can accept a rough model. Middle-out when you want a balance between speed and structure. The choice shapes the first month of work. Everything that follows shapes whether the ontology survives.

這三者沒有一個是放諸四海皆準的正確答案。當你需要互通性且能投入時間時，採用由上而下。當你本週就需要有東西能運作、且能接受一個粗略模型時，採用由下而上。當你想在速度與結構之間取得平衡時，採用由中間向外擴展。這項選擇形塑了工作的第一個月。而其後的一切，則形塑了這個本體論能否存活下去。

Before finding answers / 在尋找答案之前

Before you model a single entity, write down the questions your knowledge graph needs to answer.

在你為任何一個實體建模之前，先把你的知識圖譜需要回答的問題寫下來。

This isn’t a new idea. Gruninger and Fox formalized it in 1995 as part of their ontology development methodology. They called them “competency questions,” and the concept is straightforward: if you can’t state what you need from the ontology as a concrete, answerable question, you don’t understand the requirements well enough to start modeling.

這並不是什麼新觀念。Gruninger 與 Fox 在 1995 年將它形式化，作為他們本體論開發方法論的一部分。他們稱這些問題為「能力問題 (competency questions)」，這個概念很直接：如果你無法把你對本體論的需求陳述為一個具體、可回答的問題，那麼你對需求的理解就還不足以開始建模。

For a healthcare KG, these might look like:

對一個醫療保健知識圖譜而言，這些問題可能看起來像這樣：

  • Which patients received Drug X at facilities in Region Y during Q3?

  • 哪些病患在第三季期間於 Y 區域的院所接受了藥物 X？

  • What is the shortest referral path between Dr. A and Specialist B?

  • A 醫師與專科醫師 B 之間最短的轉診路徑是什麼？

  • Which diagnoses co-occur with Condition Z more than three times?

  • 哪些診斷與病況 Z 共同出現超過三次？

For a supply chain KG:

對一個供應鏈知識圖譜而言：

  • Which suppliers provide single-point-of-failure components?

  • 哪些供應商提供具有單點故障 (single-point-of-failure) 風險的零組件？

  • What is the average lead time from Warehouse A to Customer B across all possible routes?

  • 在所有可能的路線上，從倉庫 A 到客戶 B 的平均前置時間 (lead time) 是多少？

  • Which products share a component that has been recalled?

  • 哪些產品共用了一個已被召回的零組件？

These questions do three things at once. They scope the ontology — if no competency question requires a “Region” node, maybe region is just a property on Facility. They reveal relationships you wouldn’t have modeled otherwise — the referral path question implies you need explicit referral edges between physicians. And they give you a built-in acceptance test: when the ontology is done, run the questions as queries. If they return meaningful results, the model is fit for purpose.

這些問題同時做了三件事。它們為本體論界定範圍——如果沒有任何能力問題需要一個「區域 (Region)」節點，那麼區域或許只是「院所 (Facility)」上的一個屬性。它們揭示出你原本不會建模的關係——轉診路徑那個問題意味著你需要在醫師之間建立明確的轉診邊 (edges)。而且它們還給了你一個內建的驗收測試 (acceptance test)：當本體論完成時，把這些問題當作查詢來執行。如果它們回傳有意義的結果，那麼這個模型就符合其用途。

A 2024 study categorized competency questions into five types: scoping, validating, foundational, relationship, and metaproperty. Ontology engineers classifying their own methods into a taxonomy feels appropriately on-brand. Recent work has even explored using RAG-augmented LLMs to auto-generate competency questions from domain literature (Pan et al., 2024) — which is promising, though I’d still want a domain expert reviewing the output before it drives the model. The practical version is simpler: write 10–15 questions before touching any modeling tool, group them by the entities and relationships they require, and you have your modeling requirements document in a form that’s actually useful.

2024 年的一項研究將能力問題分類為五種類型：界定範圍型 (scoping)、驗證型 (validating)、基礎型 (foundational)、關係型 (relationship) 與元屬性型 (metaproperty)。本體論工程師把自己的方法分類進一個分類體系 (taxonomy) 裡，這感覺恰如其分地符合他們的本色。近期的研究甚至探討了使用 RAG 增強的大型語言模型 (RAG-augmented LLMs) 來從領域文獻中自動生成能力問題（Pan et al., 2024）——這很有前景，不過在它驅動模型之前，我仍會希望有一位領域專家來審閱其輸出。實務上的版本更簡單：在動用任何建模工具之前，先寫下 10 到 15 個問題，依照它們所需的實體與關係加以分組，這樣你就有了一份以真正實用的形式呈現的建模需求文件。

There’s a recent twist on this worth mentioning. A 2026 paper on the AnIML ontology introduced the idea of adversarial negative competency questions — questions the ontology should specifically not be able to answer incorrectly, mapped to known ontological anti-patterns and enforced via SHACL constraints (Morlidge et al., 2026). Not just “can the graph answer this?” but “can the graph dangerously get this wrong?”

關於這一點，最近有個值得一提的轉折。一篇 2026 年關於 AnIML 本體論的論文引入了對抗性負面能力問題 (adversarial negative competency questions) 的概念——也就是本體論應該特別不能錯誤地回答的問題，這些問題被對應到已知的本體論反模式 (anti-patterns)，並透過 SHACL 約束來強制執行（Morlidge et al., 2026）。不只是「這個圖譜能不能回答這個問題？」，而是「這個圖譜會不會危險地把這件事搞錯？」

This step gets skipped because it feels like overhead when you want to start building. I can imagine a post-mortem that skipped it and mentions refactoring the ontology within three months because the model couldn’t answer a question the business cared about.

這個步驟之所以會被略過，是因為當你想開始動手建構時，它感覺像是額外的負擔。我可以想像有一份事後檢討報告 (post-mortem) 略過了這個步驟，並提到在三個月內就得重構 (refactoring) 本體論，因為模型無法回答一個業務在意的問題。

Ontology Design Patterns / 本體論設計模式

If you’ve worked with software design patterns — Factory, Observer, Strategy — the concept transfers directly to ontology engineering.

如果你曾使用過軟體設計模式 (software design patterns)——工廠 (Factory)、觀察者 (Observer)、策略 (Strategy)——那麼這個概念可以直接轉移到本體論工程上。

Ontology Design Patterns (ODPs) are reusable, modular solutions to recurring modeling problems. Aldo Gangemi and Valentina Presutti formalized the approach in the mid-2000s, building a methodology called eXtreme Design (XD) — essentially agile ontology development, where you compose patterns rather than design from scratch.

本體論設計模式 (Ontology Design Patterns，ODPs) 是針對反覆出現的建模問題所提出的可重複使用、模組化的解決方案。Aldo Gangemi 與 Valentina Presutti 在 2000 年代中期將這種做法形式化，建立了一套名為「極限設計 (eXtreme Design，XD)」的方法論——本質上就是敏捷式 (agile) 本體論開發，你在其中是把現成的模式組合起來，而不是從頭設計。

A few patterns that come up in almost every KG project:

以下是幾乎在每個知識圖譜專案中都會出現的幾種模式：

The Participation pattern models the relationship between an entity and an event. Instead of a direct edge between Person and Event, you introduce a Participation node that captures role, time period, and context. “Dr. Nowak participated in Surgery #412 as lead surgeon on 2025–03–15” becomes one node with clean properties, rather than three separate attributes crammed onto a relationship.

參與模式 (Participation pattern) 為實體與事件之間的關係建模。你不是在「人」與「事件」之間建立一條直接的邊，而是引入一個「參與 (Participation)」節點來捕捉角色、時間區間與情境。「Nowak 醫師於 2025–03–15 以主刀外科醫師身分參與了第 412 號手術」便成為一個帶有乾淨屬性的單一節點，而不是把三個各自獨立的屬性硬塞到一條關係上。

The Sequence pattern models ordered events where the ordering itself matters. Event A happened before Event B, which caused Event C. You can model this as a chain of NEXT relationships, or use the pattern’s approach with explicit ordering nodes — particularly useful when you need to insert events into an existing sequence later.

序列模式 (Sequence pattern) 為有順序的事件建模，而順序本身是重要的。事件 A 發生在事件 B 之前，而事件 B 導致了事件 C。你可以把它建模為一連串的 NEXT 關係，或者採用該模式的做法、使用明確的排序節點——當你之後需要把事件插入一個既有的序列中時，這特別有用。

The Classification pattern separates an entity from its type assignment. Instead of a fixed label like :Person:Doctor, you create a DoctorRole node and link to it with a typed relationship. The reason: the same person can be a doctor, a patient, and a researcher simultaneously, and those role assignments can have start and end dates. If your database supports multi-labeling (like Neo4j), you can handle simple cases with :Person:Doctor directly — the separate node pays off when roles are temporal or need their own properties.

分類模式 (Classification pattern) 把實體與它的類型指派 (type assignment) 分離開來。你不是用像 :Person:Doctor 這樣的固定標籤，而是建立一個 DoctorRole（醫師角色）節點，並透過一個帶類型的關係連結到它。原因在於：同一個人可以同時是醫師、病患與研究人員，而那些角色指派可以擁有起始與結束日期。如果你的資料庫支援多重標籤 (multi-labeling)（如 Neo4j），你可以直接用 :Person:Doctor 來處理簡單的情況——當角色具有時間性，或需要擁有自己的屬性時，分離出來的節點才會帶來回報。

These are just three; the literature documents dozens more. Some KG projects I’ve read about reinvent at least two or three of these from scratch, making slightly different trade-offs each time. The result is inconsistent modeling across the graph — one part uses a participation node, another jams the same information onto edge properties. Knowing these patterns exist saves you from reinventing solutions that ontology engineers solved twenty years ago.

這只是其中三種；文獻中還記載了數十種之多。我讀到過的一些知識圖譜專案，會從頭重新發明其中至少兩三種，而且每次都做出略有不同的取捨。其結果是整個圖譜中建模方式不一致——某一部分使用參與節點，另一部分卻把同樣的資訊硬塞到邊的屬性上。知道這些模式的存在，能讓你免於重新發明那些本體論工程師早在二十年前就已解決的方案。

Ontologies change / 本體論會變

This is where most ontology guides end. You’ve picked a strategy, written competency questions, and applied some patterns — done.

大多數本體論指南到這裡就結束了。你選好了一種策略、寫好了能力問題、套用了一些模式——大功告成。

But the domain keeps moving.

但領域是不斷在變動的。

New entity types appear that didn’t exist when you designed the model. A healthcare KG built in 2019 didn’t have “Telehealth Visit” as an event type. Relationships that seemed permanent need temporal awareness — a patient’s primary physician changes, and suddenly you need both the current and the previous assignment. The business starts asking questions that the original competency set never anticipated.

新的實體類型出現了，而這些在你設計模型時並不存在。一個建於 2019 年的醫療保健知識圖譜，並沒有把「遠距醫療看診 (Telehealth Visit)」當作一種事件類型。原本看似永久不變的關係需要具備時間意識 (temporal awareness)——一位病患的主治醫師換了，於是你突然間同時需要保留目前的指派與先前的指派。業務開始問起一些原始能力問題集從未預料到的問題。

This is ontology drift: the model quietly falls out of alignment with the domain it represents, queries still run, and results look plausible. But the structural assumptions no longer match reality, and the gap widens every month nobody reviews the model.

這就是本體論漂移 (ontology drift)：模型悄悄地與它所表示的領域失去對齊，查詢仍然能執行，結果看起來也合情合理。但結構性的假設已不再與現實相符，而且每經過一個沒有人審查模型的月份，這道鴻溝就會擴大一些。

Some ontologies genuinely stabilize. Physical constants don’t change. Long-established classification systems — the periodic table, parts of biological taxonomy — shift rarely enough that updates are events, not ongoing work. If your knowledge graph models a truly static domain, a one-time design can hold indefinitely. If your domain involves people, organizations, or anything regulated — assume it won’t.

有些本體論確實會趨於穩定。物理常數不會改變。歷史悠久的分類系統——元素週期表、生物分類學 (biological taxonomy) 的某些部分——變動得夠罕見，以至於更新是一樁「事件」，而非持續性的工作。如果你的知識圖譜所建模的是一個真正靜態的領域，那麼一次性的設計可以無限期地維持下去。但如果你的領域牽涉到人、組織，或任何受監管的事物——就假設它不會穩定下來吧。

Most real-world KGs live in domains where things move: organizational structures reorganize, product lines expand, regulatory requirements update, medical protocols — they all get revised. Building an ontology for these domains as a one-time activity is the equivalent of writing a codebase with no plan for maintenance. It works until it doesn’t, and by the time someone notices, the debt is structural.

大多數真實世界的知識圖譜都棲身於事物會變動的領域中：組織結構會重組、產品線會擴張、法規要求會更新、醫療規範 (medical protocols)——它們全都會被修訂。把為這些領域建構本體論當作一項一次性活動，就等同於在編寫一個沒有任何維護計畫的程式碼庫。它會一直運作到不能運作為止，而等到有人察覺時，這筆負債已經是結構性的了。

The practical response: treat ontology maintenance the way you treat code maintenance: version the schema, review proposed changes before applying them, write new competency questions when the business asks new things. Put “ontology review” on the calendar as a recurring task — monthly for the first six months, quarterly after that. Nobody has ever described an ontology review meeting as exciting. It’s still cheaper than discovering your model drifted six months ago while debugging a production query that returns technically correct but meaningless results.

實務上的因應之道：用你對待程式碼維護的方式來對待本體論維護：為綱要建立版本控管、在套用變更之前先審查被提議的變更、當業務提出新需求時就撰寫新的能力問題。把「本體論審查」當作一項週期性任務排進行事曆——前六個月每月一次，之後每季一次。從來沒有人把本體論審查會議形容為令人興奮。但它仍然比這樣的情況划算：在除錯一個回傳了技術上正確卻毫無意義之結果的正式環境查詢時，才發現你的模型早在六個月前就已經漂移了。

When a formal ontology is overkill / 何時正式本體論會是殺雞用牛刀

Not every knowledge graph needs a formal ontology. Not every graph database even needs to be a knowledge graph.

並非每個知識圖譜都需要一套正式的本體論。甚至並非每個圖資料庫 (graph database) 都需要是一個知識圖譜。

If your data is hierarchical and you mainly need navigation and filtering, a taxonomy covers it. Product categories, org charts, geographic hierarchies. No ontology required.

如果你的資料是階層式的，而你主要需要的是導覽與篩選，那麼一個分類體系 (taxonomy) 就能涵蓋它。產品類別、組織圖、地理階層。不需要本體論。

If your data has a fixed, well-understood structure and you need validation rather than inference, a schema is enough. JSON Schema, GraphQL type definitions, or a documented property-and-label list.

如果你的資料具有固定、已被充分理解的結構，而你需要的是驗證而非推論 (inference)，那麼一個綱要就足夠了。JSON Schema、GraphQL 型別定義，或一份有文件記載的屬性與標籤清單。

A formal ontology earns its cost when you need at least one of:

當你至少需要以下其中一項時，正式本體論才值回它的成本：

  • Cross-system interoperability — merging data from sources that use different terms for the same concepts

  • 跨系統互通性 (Cross-system interoperability)——合併那些對相同概念使用不同術語的來源所提供的資料

  • Inference — if A is a subclass of B and X is an instance of A, then X is automatically an instance of B

  • 推論 (Inference)——如果 A 是 B 的子類別，而 X 是 A 的一個實例，那麼 X 就自動成為 B 的一個實例

  • Shared understanding across teams that don’t coordinate frequently enough to stay aligned informally

  • 跨團隊的共同理解——這些團隊彼此協調的頻率不足以靠非正式方式維持對齊

If none of those apply, a well-documented graph schema is lighter, easier to maintain, and gets you most of the value. Over-engineering the ontology is as real a risk as skipping it entirely.

如果以上皆不適用，那麼一個有完善文件記載的圖綱要 (graph schema) 會更輕量、更易於維護，並能讓你取得絕大部分的價值。把本體論過度工程化 (over-engineering)，與完全略過它一樣，都是真實存在的風險。

Where I’d start tomorrow / 我若明天起步會從何處著手

If I were kicking off a knowledge graph project next week, the first two weeks would look like this:

如果我下週要啟動一個知識圖譜專案，最初兩週看起來會是這樣：

  1. Write 10–15 competency questions before opening any tool. If the business stakeholders can’t articulate the questions, the project isn’t ready for a knowledge graph.

  2. 在開啟任何工具之前，先寫下 10 到 15 個能力問題。如果業務利害關係人 (stakeholders) 無法清楚地表述這些問題，那麼這個專案還沒準備好導入知識圖譜。

  3. Pick a middle-out starting point — POLE+O or a domain-specific equivalent — and get a queryable graph running within the first week. Query it immediately, even with incomplete data.

  4. 選定一個由中間向外擴展的起點——POLE+O 或某個特定領域的對應方案——並在第一週內就讓一個可查詢的圖譜運作起來。立刻去查詢它，即使資料還不完整也一樣。

  5. Before inventing a modeling solution for participation, sequencing, or classification, check whether there’s an established ontology design pattern for it. Somebody solved it already.

  6. 在為參與、排序或分類發明一套建模解決方案之前，先查查看是否已有一個現成的本體論設計模式可以套用。早就有人解決過這個問題了。

  7. Schedule a monthly ontology review for the first six months. Same rigor as a code review, applied to the model.

  8. 為最初六個月安排每月一次的本體論審查。把與程式碼審查 (code review) 相同的嚴謹度，施用在這個模型上。

The oldest methodology referenced in this article is from 1995. The most recent research still cites it. Thirty years, and the core insight hasn’t moved: start with questions, not entities. Build to evolve, not to finish.

本文所引用最古老的方法論來自 1995 年。而最新的研究仍在引用它。歷經三十年，其核心洞見卻不曾動搖：從問題開始，而非從實體開始。為了演進而建構，而非為了完工而建構。

Does your team treat the ontology as something that changes, or was it designed once and shipped?

你的團隊是把本體論視為一個會變動的東西，還是它只被設計過一次就交付出去了？

Resources / 資源

🔤 關鍵術語

英文 繁中譯名 文章中的脈絡 / 簡短說明
Knowledge Graph (KG) 知識圖譜 全文核心：以節點與關係表示領域知識的圖資料結構
Ontology 本體論／本體 定義圖中實體類型、屬性與關係的形式化模型，文章主題
Ontology Engineering 本體工程 擁有 30 年方法論的學術領域，作者嘗試翻譯成開發者語言
POLE+O POLE+O（五型本體） Neo4j「Create Context Graph」提出的五種實體分類起點
Upper Ontology 上層本體 如 BFO、DOLCE 等高度抽象、跨系統互通的本體
BFO (Basic Formal Ontology) 基礎形式本體 自上而下方法所採用的上層本體範例
DOLCE DOLCE 本體 另一個遵循 top-down 路線的上層本體
Top-down / Bottom-up / Middle-out 由上而下／由下而上／中間外擴 Uschold & King 提出的三種本體識別策略
Competency Questions 能力問題 Gruninger & Fox 提出，建模前先寫下圖譜需回答的具體問題
Adversarial Negative Competency Questions 對抗式負向能力問題 AnIML 本體提出，界定圖譜「不應錯誤回答」的問題
SHACL Constraints SHACL 約束 用以強制執行反模式檢查的圖形驗證約束語言
Ontology Design Patterns (ODPs) 本體設計模式 可重用、模組化的建模解法，類比軟體設計模式
eXtreme Design (XD) 極限設計 Gangemi & Presutti 提出的敏捷式、組合模式的本體開發方法
Participation Pattern 參與模式 以中介節點捕捉實體與事件間的角色、時間與情境
Sequence Pattern 序列模式 為有序事件建模，使用 NEXT 關係或顯式排序節點
Classification Pattern 分類模式 將實體與其類型指派分離，支援暫時性與多重角色
Multi-labeling 多標籤 Neo4j 等資料庫支援單一節點掛多個標籤（如 :Person:Doctor）
Ontology Drift 本體漂移 模型悄然與領域失準，查詢仍可跑但結果失去意義
Inference 推理 形式本體價值之一：由子類別關係自動推導實例類型歸屬
Cross-system Interoperability 跨系統互通性 合併使用不同術語的資料來源，形式本體的關鍵效益
Taxonomy 分類法 階層式資料只需導覽與篩選時的輕量替代方案
RAG-augmented LLMs RAG 增強型大型語言模型 近期研究用以自領域文獻自動生成能力問題