你的知識圖譜大概不需要圖資料庫¶
文章資訊
作者：Michael Sakhatsky 日期：2026-06-13
原文標題：You Probably Don’t Need a Graph Database for Your Knowledge Graph
📝 重點摘要¶
TL;DR¶
多數企業用規則引擎與 Datalog 落地領域知識，比上 Neo4j 更快更省。
核心問題¶
業界把「LLM 需要領域知識 grounding」直接推論成「需要 Neo4j 圖資料庫」。作者質疑這條「需要本體論 → RDF → 圖 → 圖資料庫」的推理鏈每一環都比表面脆弱，主張多數企業有更務實的替代路徑。
關鍵發現 / 數據¶
- 圖資料庫並非新技術：1969 年 CODASYL 網路模型已將關係視為一等公民，Honeywell、HP、DEC、Oracle 在 1970 年代皆出貨。
- 圖資料庫真正獨特優勢僅在「未知深度遞迴查詢」（供應鏈、機械裝配、網路路徑），是真實但狹窄的強項。
- OWL 2 Full 不可判定且學界外幾乎無人實作；Ontotext、Stardog 僅支援 QL/RL profile，多數通用圖庫完全不支援。
- 製藥案例（SNOMED CT）：因圖庫不支援 EL++ 推理，分類須用 ELK reasoner 在資料庫外批次跑，使 pipeline 複雜化。
- 圖庫只存 A-Box（斷言）不存 T-Box（規則），SPARQL/Cypher/Gremlin 無法做推理；邊的 arity 僅限 2。
方法亮點¶
- 區分「關係重要」的三種意涵：存在性、可遍歷性、語意——圖庫擅長前兩者，語意屬邏輯而非圖論。
- 圖分析（連通性、中心性、GNN）應用 NetworkX、Spark GraphFrames、PyTorch 在資料庫外做，而非 Cypher。
- 替代路徑：先用 MCP server 把企業現有規則引擎（Drools、IBM ODM、DMN）暴露給 LLM；再導入 Datalog（可判定、快、原生支援 facts/predicates，如 Soufflé、DDlog）。
對我的研究有用嗎？¶
有參考價值。它釐清了 GraphRAG 中「結構檢索」與「真正邏輯推理」的界線——前者圖庫可勝任，後者需外部 reasoner，對設計 reasoning-grounded 系統是重要提醒。A-Box/T-Box、Description Logic、Datalog 可判定性等概念，可作為評估知識表示層方案的框架，避免盲目預設圖資料庫。
評語¶
值得一讀，論證紮實、史料與技術細節到位；但屬意見型立場文，缺實證 benchmark，且作者立場明顯反圖庫，需自行平衡。
🌐 中英對照¶
Author: Michael Sakhatsky Published: Source: https://medium.com/@msakhatsky/you-probably-dont-need-a-graph-database-for-your-knowledge-graph-7178054fe3d3 Fetched: 2026-06-13T00:27:53.967490
You Probably Don't Need a Graph Database for Your Knowledge Graph / 你的知識圖譜大概不需要圖資料庫¶
Rethinking the default choice for grounding LLMs in institutional knowledge / 重新思考以機構知識來奠基大型語言模型 (LLM) 的預設選擇¶
TL;DR — Graph databases are great at what they do. But the leap from "we need to ground our LLM in domain knowledge" to "we need Neo4j" skips several questionable assumptions. For most enterprise teams, rules engines and Datalog are a faster, cheaper, and more pragmatic path.
太長別讀（TL;DR） —— 圖資料庫 (Graph Database) 在其本職工作上表現出色。但是從「我們需要用領域知識來奠基我們的 LLM」跳躍到「我們需要 Neo4j」，這之間跳過了好幾個值得質疑的假設。對多數企業團隊而言，規則引擎 (Rules Engine) 與 Datalog 才是更快、更便宜、也更務實的路徑。
If you follow any discussion about grounding LLMs with enterprise knowledge, the conventional wisdom goes something like this: to reduce hallucinations and inject domain context, you need an explicit machine-readable specification of shared concepts — an ontology. Ontologies are RDF graphs. RDF lives in graph databases. Therefore, buy Neo4j (or Stardog, or Ontotext GraphDB, or Neptune).
如果你關注過任何關於「用企業知識奠基 LLM」的討論，傳統觀點大致是這樣的：為了減少幻覺 (hallucination) 並注入領域脈絡，你需要一份明確、機器可讀的共享概念規格——也就是本體論 (Ontology)。本體論是 RDF 圖。RDF 存在於圖資料庫中。因此，買 Neo4j（或 Stardog，或 Ontotext GraphDB，或 Neptune）吧。
After spending a few years building semantic layers and knowledge graphs for clients, I've come to think this chain of reasoning is weaker than it looks. Not because graph databases are bad — they're excellent at what they do — but because the leap from "we need institutional knowledge in our agentic workflow" to "we need a graph database" skips several steps that deserve scrutiny.
在花了幾年時間為客戶建立語義層 (semantic layer) 與知識圖譜 (Knowledge Graph) 之後，我逐漸認為這條推理鏈比它看起來要脆弱。並不是因為圖資料庫不好——它們在本職工作上極為出色——而是因為從「我們的代理式工作流程 (agentic workflow) 需要機構知識」跳躍到「我們需要一個圖資料庫」，跳過了好幾個值得仔細審視的步驟。
The argument I'm pushing back on / 我所反駁的論點¶
Most "you need a graph DB" pitches reduce to four claims:
大多數「你需要圖資料庫」的推銷說詞，可以歸結為四個主張：
- We need an ontology to constrain LLM reasoning.
我們需要一個本體論來約束 LLM 的推理。
- The standard format for ontology is RDF.
本體論的標準格式是 RDF。
- RDF is inherently a graph.
RDF 本質上就是一個圖。
- Therefore, we need a graph database.
因此，我們需要一個圖資料庫。
Each link is weaker than it looks. Let's walk through them.
每一個環節都比它看起來要脆弱。讓我們逐一檢視。
Press enter or click to view image in full size
按 enter 或點擊以全尺寸檢視圖片
The reasoning chain commonly used to justify graph databases — and the weak link under each step.
常被用來合理化圖資料庫的推理鏈——以及每個步驟下的脆弱環節。
Do we need a graph database to work with relationships? / 我們需要圖資料庫來處理關聯嗎？¶
Neo4j, the most familiar player in this field, states that "unlike other databases, relationships take first priority in graph databases." It's positioned as a new technology that solves problems older databases handle poorly.
Neo4j 是這個領域中最為人熟知的玩家，它聲稱「與其他資料庫不同，關聯 (relationship) 在圖資料庫中享有最高優先權。」它被定位為一項解決舊資料庫處理不佳之問題的新技術。
It is, in fact, neither new nor uniquely capable. The CODASYL network database model — published in 1969 — already treated relationships as first-class citizens. Honeywell, HP, DEC, and Oracle all shipped popular network databases in the 1970s.
事實上，它既不新穎，也並非獨具能力。早在 1969 年發表的 CODASYL 網狀資料庫模型 (network database model)，就已經將關聯視為一等公民。Honeywell、HP、DEC 與 Oracle 在 1970 年代都推出過熱門的網狀資料庫。
Relational databases are also based on relationships (the name is a hint). Any data in labeled property graph format can be stored in an RDBMS without losing semantics. So why does GraphDB exist?
關聯式資料庫 (relational database) 同樣是建立在關聯之上的（這個名字就是提示）。任何以標記屬性圖 (Labeled Property Graph) 格式存在的資料，都能在不喪失語義的情況下儲存於 RDBMS 中。那麼，圖資料庫為何存在？
The honest answer is: recursive queries. Although SQL:1999 introduced recursive CTEs, traditional RDBMS vendors implemented them poorly or not at all. Graph databases shine when you need to traverse relationships of unknown depth — supply chains, mechanical assemblies, network paths. That's a real but narrow strength, which is why graph databases survived in niche markets like supply chain management and mechanical design even before the current AI hype reinvigorated interest in them.
誠實的答案是：遞迴查詢 (recursive query)。儘管 SQL:1999 引入了遞迴的共用資料表運算式 (recursive CTE)，傳統的 RDBMS 廠商卻實作得很差，甚至根本沒有實作。當你需要遍歷 (traverse) 深度未知的關聯時——供應鏈、機械組裝、網路路徑——圖資料庫便能大放異彩。這是一項真實但狹隘的優勢，這也是為什麼即便在當前 AI 熱潮重新點燃人們的興趣之前，圖資料庫早已能在供應鏈管理與機械設計等利基市場存活下來。
The case for GraphDB also conflates three different things people mean by "relationships matter":
支持圖資料庫的論點，也混淆了人們所謂「關聯很重要」時實際指涉的三件不同的事：
- Existence. The fact that A is connected to B is itself information. In signal intelligence, knowing two parties communicate matters even without the message.
存在性 (Existence)。 A 與 B 相連這件事本身就是資訊。在訊號情報 (signal intelligence) 中，即便沒有訊息內容，知道兩方有通訊往來本身就很重要。
- Traversal. Can I get from A to C through some chain of edges?
遍歷 (Traversal)。 我能否透過某條邊 (edge) 的鏈路，從 A 走到 C？
- Semantics. What does the edge mean? Is it transitive, reflexive, symmetric, or functional?
語義 (Semantics)。 這條邊意味著什麼？它是遞移的 (transitive)、自反的 (reflexive)、對稱的 (symmetric)，還是函數型的 (functional)？
GraphDB handles existence and traversal well. It does not handle semantics — that's the domain of logic, not graph theory.
圖資料庫能妥善處理存在性與遍歷，卻無法處理語義——那是邏輯 (logic) 的範疇，而非圖論 (graph theory) 的範疇。
And how is a graph database actually related to graphs? / 那麼，圖資料庫究竟和「圖」有什麼關係？¶
Most introductions to graph databases open with a picture of nodes and edges. That's pedagogically helpful, but it's also where engineering intuition breaks down.
大多數對圖資料庫的介紹，都以一張節點 (node) 與邊的圖示作為開場。這在教學上很有幫助，但這同時也是工程直覺開始失靈之處。
Graph theory is taught in discrete mathematics departments, alongside abstract algebra and group theory — not geometry. It's mostly concerned with global structural properties (connectivity, components, centrality) and local topology. In practice, this is the domain of graph analytics: traditional algorithms and modern approaches like graph neural networks (GNN), used to surface network-level characteristics.
圖論是在離散數學 (discrete mathematics) 領域中與抽象代數 (abstract algebra) 和群論 (group theory) 一同教授的，而非幾何學。它主要關注的是全域結構性質（連通性 connectivity、連通分量 components、中心性 centrality）以及局部拓撲 (local topology)。在實務上，這是圖分析 (graph analytics) 的範疇：傳統演算法以及如圖神經網路 (Graph Neural Network, GNN) 這類現代方法，用以揭示網路層級的特徵。
Here's the awkward truth: the query languages graph databases use — SPARQL, Cypher, Gremlin — are great at local traversal but poorly suited to analytics. Neo4j ships a limited set of analytics algorithms, but extending them to novel use cases is hard. AWS even split this concern: Neptune Analytics is a separate product with an in-memory representation specifically for analytics workloads. In many cases, the right answer for analytics is NetworkX (small graphs), Spark GraphFrames (large ones), or just PyTorch (for GNNs) — outside the database entirely.
這裡有個尷尬的事實：圖資料庫所使用的查詢語言——SPARQL、Cypher、Gremlin——擅長局部遍歷，卻不太適合做分析。Neo4j 隨附了一組有限的分析演算法，但要將它們延伸到新穎的使用情境卻很困難。AWS 甚至把這個問題拆分開來：Neptune Analytics 是一項獨立的產品，具備專為分析工作負載設計的記憶體內 (in-memory) 表示法。在許多情況下，做分析的正解是 NetworkX（小型圖）、Spark GraphFrames（大型圖），或乾脆用 PyTorch（用於 GNN）——完全在資料庫之外進行。
Do we need graphs to represent ontologies? / 我們需要用「圖」來表示本體論嗎？¶
Practitioners often argue that there's only one canonical way to represent ontologies — RDF — so a triple store or GraphDB is required. This is also less settled than it sounds.
從業者常主張，表示本體論只有一種規範方式——RDF——因此非得使用三元組儲存庫 (triple store) 或圖資料庫不可。但這件事其實也不如聽起來那般有定論。
People have been arguing about ontology since Aristotle. Even narrowing to technical ontology, there's no commonly accepted definition, let alone a universal standard. The closest thing is ISO/IEC 21838:2021 (Top-Level Ontologies). What we do have is W3C's family of Semantic Web languages — RDF, RDFS, OWL — alongside others like SKOS. In this context, ontology is viewed as equivalent to a Description Logic knowledge base.
人們自亞里斯多德以來就一直在爭論本體論。即便縮小到技術性的本體論，也沒有一個普遍被接受的定義，更遑論一套通用的標準了。最接近的東西是 ISO/IEC 21838:2021（頂層本體論，Top-Level Ontologies）。我們確實擁有的，是 W3C 的語義網 (Semantic Web) 語言家族——RDF、RDFS、OWL——以及像 SKOS 這類的其他語言。在這個脈絡下，本體論被視為等同於一個描述邏輯 (Description Logic) 知識庫。
The Semantic Web, as Tim Berners-Lee envisioned it, was supposed to map interactions between sites and agents across the web. In that context, graphs made perfect sense. The original vision didn't pan out — most of the web isn't semantic in the way he imagined — though pieces of the stack found commercial success (Schema.org and JSON-LD are on essentially every major site for SEO). RDF itself followed the same trajectory as XML: a clean idea and a few pages of DTDs, followed by abominations like XML Schema that made it equally inconvenient for humans and machines, until JSON ate its lunch.
提姆·柏內茲-李 (Tim Berners-Lee) 所構想的語義網，原本是要描繪整個網路上各網站與代理 (agent) 之間的互動。在那個脈絡下，圖完全合情合理。最初的願景並未實現——大部分的網路並不像他所想像的那樣具有語義——儘管這套技術堆疊的部分元件取得了商業成功（為了搜尋引擎最佳化 (SEO)，Schema.org 與 JSON-LD 基本上出現在每一個主流網站上）。RDF 本身則走上了與 XML 相同的軌跡：一個簡潔的構想加上幾頁的 DTD，接著演變出像 XML Schema 這類讓人類與機器同樣不便使用的可憎之物，直到 JSON 搶走了它的飯碗。
What's the practical state of OWL today? OWL 2 Full is undecidable, and almost no one implements it outside academia. OWL 2 DL is decidable but expensive. Specialized systems like Ontotext GraphDB and Stardog implement only the QL or RL profiles. Most general-purpose graph databases implement none of it.
OWL 如今的實務狀況如何？OWL 2 Full 是不可判定的 (undecidable)，而且學術界之外幾乎沒有人實作它。OWL 2 DL 是可判定的 (decidable)，但代價高昂。像 Ontotext GraphDB 與 Stardog 這類專門系統，也只實作了 QL 或 RL 子集 (profile)。而大多數通用型的圖資料庫則一概都沒有實作。
The pharmaceutical industry is a useful case study. Pharma depends on enormously complex ontologies like SNOMED CT. For performance, they often use a graph database as a backend in tools like OLS and OxO. But because these databases don't support EL++ inference, classification has to be run outside the database in batch mode using the ELK reasoner — which significantly complicates the pipeline.
製藥業是一個有用的案例研究。製藥業仰賴像 SNOMED CT 這樣極其複雜的本體論。為了效能，他們經常在 OLS 與 OxO 這類工具中使用圖資料庫作為後端。但由於這些資料庫不支援 EL++ 推論 (inference)，分類工作必須在資料庫之外、以批次模式使用 ELK 推理機 (reasoner) 來執行——這大幅增加了流程管線 (pipeline) 的複雜度。
And do we even need graphs to represent ontologies in the first place? The dominant framework for ontology design is logical theory, which is unrelated to graph theory. Graph analytics may help with ontology engineering and debugging, but you'd still typically run it outside the GraphDB. To paraphrase George Box: all models are wrong, some are useful — and the graph model isn't particularly useful for representing corporate knowledge.
而且，我們一開始究竟有沒有必要用圖來表示本體論？本體論設計的主流框架是邏輯理論 (logical theory)，這與圖論毫無關係。圖分析或許有助於本體論工程與除錯，但你通常仍然會在圖資料庫之外執行它。套用喬治·博克斯 (George Box) 的話來改寫：所有模型都是錯的，但有些是有用的——而圖模型對於表示企業知識而言，並不特別有用。
Where graph databases fall short for institutional knowledge / 圖資料庫在機構知識上的不足之處¶
Let me be specific about the gaps.
讓我具體說明這些缺口。
They handle facts but not rules. In description logic terms, GraphDB stores A-Boxes (assertions) but not T-Boxes (terminology and rules). They have no formal schema, which is flexible — but it means SPARQL, Cypher, and Gremlin can't be used for inference. You need external reasoners like ELK, Pellet, or Apache Jena. Even an EL-profile ontology generally cannot be translated into native graph queries; efficient inference requires algorithms like SLG resolution with tabling. GraphRAG can plug structural knowledge into an agentic workflow, but if real inference is required, the integration gets ugly. You don't just have to explain your graph model to the LLM; you also have to explain how to interpret each kind of edge.
它們處理事實，但不處理規則。 以描述邏輯的術語來說，圖資料庫儲存的是 A-Box（斷言 assertion），而非 T-Box（術語與規則）。它們沒有正式的綱目 (schema)，這固然有彈性——但這也意味著 SPARQL、Cypher 與 Gremlin 都無法用於推論。你需要像 ELK、Pellet 或 Apache Jena 這樣的外部推理機。即便是 EL 子集的本體論，通常也無法被轉譯成原生的圖查詢；高效率的推論需要像帶有列表化 (tabling) 的 SLG 解析 (SLG resolution) 這類演算法。GraphRAG 能把結構性知識接入代理式工作流程，但若需要真正的推論，這種整合就會變得很醜陋。你不僅得向 LLM 解釋你的圖模型，還得解釋如何詮釋每一種邊。
No formal schema means no structural validation. High-end vendors like Ontotext have ontology engineering tooling, but most don't. Any OWL ontology can be translated into a Labeled Property Graph without losing information — but there's no canonical way to do it, so every team rolls its own.
沒有正式綱目，就意味著沒有結構性驗證。 像 Ontotext 這樣的高階廠商備有本體論工程工具，但大多數廠商都沒有。任何 OWL 本體論都能在不損失資訊的情況下被轉譯為標記屬性圖——但並沒有一種規範的做法，於是每個團隊都得自行打造一套。
Predicates are limited to arity 2. A graph edge connects exactly two nodes. Anything more requires hypergraphs or reification, both of which make interpretation messy and undermine the "easy to reason about" pitch.
述詞 (predicate) 被限制在二元數 (arity 2)。 一條圖的邊恰好連接兩個節點。任何超過這個數目的關係，都需要超圖 (hypergraph) 或具體化 (reification)，而這兩者都會讓詮釋變得一團亂，並削弱了「易於推理」這個賣點。
The security model is underdeveloped. If there's a path from A to C through D but the user can't see D, what happens? The model becomes non-monotonic in ways that depend on the user's role.
安全模型尚不成熟。 如果有一條從 A 經由 D 到 C 的路徑，但使用者看不到 D，會發生什麼事？這個模型會以取決於使用者角色的方式變成非單調的 (non-monotonic)。
Ontology engineering is a rare, expensive skill. Building something like SNOMED takes years and serious money. For most companies, building a real ontology from scratch is out of reach — and a graph database without an ontology is just a less convenient relational database.
本體論工程是一項稀有而昂貴的技能。 打造像 SNOMED 這樣的東西需要花上數年時間與大筆金錢。對大多數公司而言，從零開始建立一個真正的本體論是遙不可及的——而一個沒有本體論的圖資料庫，不過就是一個比較不方便的關聯式資料庫罷了。
So what should you use instead? / 那麼，你應該改用什麼？¶
Encoding domain knowledge in machine-readable form isn't a new idea. It traces back to the 1970s — Marvin Minsky and Edward Feigenbaum's work on knowledge representation. Before we called them "knowledge graphs," they were called knowledge bases. The original promise of expert systems wasn't fully delivered, but the underlying ideas were sound, and they're due for a revisit.
以機器可讀的形式編碼領域知識並不是什麼新點子。它可以追溯到 1970 年代——馬文·明斯基 (Marvin Minsky) 與愛德華·費根鮑姆 (Edward Feigenbaum) 在知識表示 (knowledge representation) 上的研究工作。在我們稱它們為「知識圖譜」之前，它們被稱作知識庫 (knowledge base)。專家系統 (expert system) 最初的承諾並未完全兌現，但其背後的構想是健全的，如今也該重新審視一番了。
While currently out of fashion, these technologies never actually left the enterprise. Most businesses with complex policy logic already use rule systems — Drools, IBM ODM (formerly iLog), DMN-based engines. Step one for many teams isn't building an ontology. It's exposing the rules they already have to LLMs through MCP servers.
儘管目前已經退流行，這些技術其實從未離開過企業界。大多數具有複雜政策邏輯的企業，早已在使用規則系統——Drools、IBM ODM（前身為 iLog）、以 DMN 為基礎的引擎。對許多團隊而言，第一步並不是建立一個本體論，而是透過 MCP 伺服器，將他們既有的規則暴露給 LLM。
Step two is logic programming. Datalog has had a quiet renaissance over the last decade — it guarantees decidability, runs fast, and works natively with facts and predicates. There are several embeddable open-source implementations (Soufflé, DDlog, and Datomic-family stores) that slot cleanly into a microservice. For richer cases, Prolog is still around. Prolog programmers are scarce, but Prolog is much easier to learn than OWL 2, and Datalog is easier still.
第二步是邏輯程式設計 (logic programming)。Datalog 在過去十年間悄然復興——它保證可判定性、執行速度快，並且原生地與事實 (fact) 和述詞協同運作。市面上有好幾個可嵌入的開源實作（Soufflé、DDlog 以及 Datomic 家族的儲存庫），能夠乾淨俐落地嵌入到微服務 (microservice) 之中。對於更豐富的情境，Prolog 也依然健在。Prolog 程式設計師很稀缺，但 Prolog 比 OWL 2 容易學得多，而 Datalog 又更容易上手。
Press enter or click to view image in full size
按 enter 或點擊以全尺寸檢視圖片
Press enter or click to view image in full size
按 enter 或點擊以全尺寸檢視圖片
The advantage of this route is leverage. You build on assets the company already has. Rules are artifacts that business stakeholders can read. And because inference is delegated to the knowledge base, agent integration gets simpler — agents don't need to construct elaborate traversal queries; they just ask questions. While some specialized graph databases like Stardog embed OWL 2 RL reasoners and reduce the component count, the rules-engine path is still simpler for most teams.
這條路徑的優勢在於槓桿作用。你是在公司既有的資產之上進行構建。規則是商業利害關係人 (stakeholder) 看得懂的產出物 (artifact)。而且，因為推論被委派給了知識庫，代理的整合也變得更簡單——代理不需要建構繁複的遍歷查詢；它們只需要提問。雖然某些像 Stardog 這樣的專門圖資料庫內嵌了 OWL 2 RL 推理機並減少了元件數量，但對大多數團隊而言，規則引擎這條路仍然更為簡單。
Conclusion / 結論¶
Yes, GenAI needs access to machine-readable institutional knowledge. Without it, you can't ground reasoning, reduce hallucinations, or verify outputs. But time-to-market matters too, and most companies don't have the budget or specialists for the full RDF/OWL or LPG journey.
是的，生成式 AI (GenAI) 確實需要存取機器可讀的機構知識。沒有它，你就無法奠基推理、減少幻覺，或驗證輸出。但上市時間 (time-to-market) 同樣重要，而大多數公司並沒有足夠的預算或專家去走完整套 RDF/OWL 或 LPG（標記屬性圖）的旅程。
There are good reasons to pick a graph database. There are also good reasons not to. Either way, GraphDB shouldn't be the default — and it certainly shouldn't be the first choice — for codifying institutional knowledge. Other options often work better in context, and they deserve a serious look before you commit.
選擇圖資料庫有其充分的理由，不選擇它也有其充分的理由。無論如何，在將機構知識編碼成文這件事上，圖資料庫都不該是預設選項——而且它當然更不該是第一選擇。其他選項在特定情境下往往運作得更好，在你做出承諾之前，它們值得你認真審視一番。
🔤 關鍵術語¶
| 英文 | 繁中譯名 | 文章中的脈絡 / 簡短說明 |
|---|---|---|
| GraphRAG | 圖譜檢索增強生成 | 把結構化知識接入 agentic workflow，但若需真正推理則整合困難 |
| Knowledge Graph | 知識圖譜 | 全文主題；作者主張不一定需要圖資料庫來承載 |
| Ontology | 本體論／本體 | 共享概念的機器可讀規格，用以約束 LLM 推理 |
| RDF (Resource Description Framework) | 資源描述框架 | W3C 語意網語言，常被視為本體的標準格式，文中質疑此預設 |
| OWL (Web Ontology Language) | 網路本體語言 | OWL 2 Full 不可判定、DL 昂貴，多數圖資料庫不實作 |
| Description Logic | 描述邏輯 | 本體被視為等價於描述邏輯知識庫；A-Box/T-Box 由此而來 |
| A-Box / T-Box | 斷言盒／術語盒 | 圖資料庫只存事實(A-Box)，不存規則(T-Box) |
| Triple Store | 三元組儲存庫 | 用來存放 RDF 的資料庫類型 |
| Labeled Property Graph (LPG) | 標籤屬性圖 | 可無損承載關聯資料，但缺乏標準轉換方式 |
| SPARQL / Cypher / Gremlin | （圖查詢語言） | 擅長局部 traversal，但不適合分析、無法做推理 |
| Graph Neural Networks (GNN) | 圖神經網路 | 現代圖分析方法，通常在資料庫外（PyTorch）執行 |
| Recursive CTE | 遞迴共用資料表運算式 | SQL:1999 引入；圖資料庫存在的真正理由是遞迴查詢 |
| Entity Traversal | 實體遍歷 | 沿未知深度的邊鏈走訪，圖資料庫的核心強項 |
| Reasoner (ELK / Pellet / Jena) | 推理機 | 圖資料庫無法推理，需外部推理機；ELK 用於 EL++ 分類 |
| SLG Resolution with Tabling | 帶製表的 SLG 消解 | 高效推理所需演算法，原生圖查詢難以表達 |
| Reification / Hypergraph | 具體化／超圖 | 處理 arity > 2 的謂詞，使解讀變得複雜 |
| Datalog | Datalog 邏輯程式語言 | 保證可判定、執行快，作者推薦的務實替代路徑 |
| Prolog | Prolog 邏輯程式語言 | 比 OWL 2 易學的邏輯程式方案 |
| MCP Server | MCP 伺服器 | 把企業既有規則暴露給 LLM 的整合方式 |
| SNOMED CT | SNOMED CT 臨床術語系統 | 製藥業使用的超複雜本體案例 |