本篇解决什么：把被三方人马同时使用的「本体」这个词拆开，让你下次开选型会时能当场指出对方站在哪一派。这是系列开篇，无前置篇目。
读完能得到：一张三派对照表、一条「本体 ⊃ 语义层 ⊃ 指标层」的判据，以及本系列为什么不走完备 OWL 路线的理由。
一、同一个"给 GMV 建本体"的指令，收到三种回答
我在三个不同场合做过同一个实验：对着三个人，提出同一个要求——"给我们的 GMV 建一个本体。"三个人的第一反应都合理，三个人的产物互不兼容。
第一位做知识图谱出身。他先问我命名空间用哪个 URI，然后说 GMV 不该做成类（owl:Class），应该做成属性；订单和客户之间的关系要写成对象属性（owl:ObjectProperty）并标上基数；最后配一份 SHACL 形状文件来校验这份本体自己有没有写错。交付物是.ttl，查询语言是 SPARQL。
第二位刚从一场 Palantir Foundry 的分享会回来。他说 GMV 不是一个孤立数字，它挂在"订单"这个对象类型（Object Type）上：先建对象、属性（Property）、链接（Link Type），再把"重算昨日 GMV 并推送给类目负责人"注册成动作类型（Action Type），权限和对象在同一层。交付物是一个既能查也能写回业务系统的语义运行时。
第三位是数仓老同事。他反问："为什么要用本体这个词？"然后打开仓库，在指标目录里加了一条定义：SUM(pay_amount)，过滤pay_status = 'paid'，时间维用ordered_at，粒度（grain）到订单。他说这叫口径（metric definition），不叫本体。
三个人都在说"本体"，没有一个人说错自己那一派。但他们的目标不同、产物不同、改一次的成本差一个数量级、签字的人也不同。
这个分歧是有价格的。本仓库参考实现在受控数据上量过两笔账：漏掉一条默认过滤规则（把软删除单和压测单挡在业绩之外），同一批订单的合计从 5400 变成 16599，偏差 +207.4%；join 方向走错造成的重复计数（fan-out），偏差甚至不是常数——同一份 seed 上三个一级类目分别是 0%、+38.9%、+91.7%，合计 +33.3%（源：05 §5.3；12§五 把它概括为 +33%~92%。机制留到第 04、07 篇展开）。两类错误有同一个特点：SQL 执行成功，不报错，结果是错的。它们能不能在编译期被挡住，取决于上面三种人里，谁的说法变成了团队里那份可以被机器检查的文件。
所以"我们要不要上本体"这句话，在把三派划清之前，等价于没问。这就是选型失败的第一现场。本篇只做一件事：划清。
二、词源与定义：这条定义，工程界只留下了一半
“本体"是从哲学借来的词。本系列统一写"本体”，不写"本体论"——后者是哲学分支，讨论的是一般存在的范畴，跟你要建的这张表没关系。工程语境里被引用最多的定义有两条。
Gruber 的定义：本体是"对概念化的显式规范"，英文原文是 “an ontology is an explicit specification of a conceptualization”（源：00 大纲 §第 01 篇二）。逐词拆：conceptualization（概念化）指你对某个领域"存在哪些东西、它们如何关联"的一套切分——同一批数据，切成"订单—订单行"还是切成"交易—商品"，是两套概念化，没有谁天然正确；explicit specification（显式规范）指这套切分不能只留在某个人的脑子里，要被明确写出来、别人能读到、能被反驳。
Studer 等人把这一类定义收敛成四个特征（源：00 大纲 §第 01 篇二）：
- conceptualisation（概念化）：它是对世界的切分，不是世界本身，所以永远允许重新切；
- explicit（显式）：假设、术语、约束都被写出来，不靠口口相传；
- formal（形式化）：用符号系统表达，机器可以读取并处理；
- shared（共享）：反映的是共同体的共识，不是某个人的私有模型。
现在说本篇最重的一句判断：工程实践实际上只保留了这四个特征里的一半。
被保留的是 explicit 和 formal。这一半活得很好，好到可以直接拿源码当证据：本次调研把十个开源仓库并排拆开对齐，"本体到底由哪些部件构成"收敛成了六层——物理目录、语义对象、关系、指标、术语、治理与执行，每一层都是写进文件或元数据表、由代码去检查的东西，没有一层是自由散文（源：01a §11）。同节还有一条跨仓一致的结论更狠：审核状态必须是机器可查的字段，不能是流程共识（源：01a §11）。这句话就是 explicit + formal 推到极端的样子：连"谁同意了"都得是个字段。反过来，任何写不进文件、机器读不懂的约定，在实践中等于不存在。
被改写的是另外一半。
概念化的完备性不再被追求。02§3 讲最小可行本体（MVO）时开门见山：“不要一开始就追求完备 OWL 本体”，理由是企业问数失败案例的绝大多数根因，用五类条目就能覆盖：terms 术语、entities & properties 实体与属性、links/joins 关系、metrics 指标、rules 规则（源：02 §3）。注意这五类里没有一个需要公理推理。
shared 没有丢，但被换了实现方式。它不再由本体公理自动保证，而是被拆成两件笨东西：一份可审计的状态字段，和一个明确的责任人。三派产物里唯一把责任人写进定义的地方，是02§1 划界表中指标层那一栏——“数据 + 业务方共签”。也就是说，共识由评审（review）来兜底，而不是由逻辑系统来兜底。这条做法在第 03 篇会具体化成 Git PR 加 CI 门禁。
这笔账在12§五 有一句最直白的版本：“该不该上 OWL/RDF？除非需要公理推理或多系统语义互操作。工程上’能挡住错误的最小声明集’（基数 + 方向 + 粒度 + 可加性 + 默认过滤）收益占九成，成本占三成。”（源：12 §五）
于是本篇留下一条判据，后面十四讲会反复用到：一个字段值不值得写进本体，看它能不能变成一条校验规则或一次编译决策。只能变成散文的，最终都会变成争吵。
⚠️ 未核实：Gruber 与 Studer 的两段表述是本系列大纲指定的教科书式引用。本次调研的五份素材（
02／03／04／12／01a）都没有附这两条定义的原始论文年份、期刊与页码，所以本文只复述定义内容与四个特征的英文原词，不给年份和文献号。需要对外引用时请回到原论文核对。
三、三派分岔：目标、产物、变更成本
图 1-1｜读这张图看什么：横向读一行——同一行的三个框是同一个流派的"目标 / 产物 / 代价"；竖向读是在比较三家谁改得起。发现自己和同事分属不同行，那场会就一定吵不完。
先说形式本体派：目标是互操作与推理。这一支的产物是 TTL + SPARQL，外加一台描述逻辑推理机（Description Logic reasoner：把本体写成公理之后，能推出你没显式写下的结论）。它真正独特的能力就是"推出没写出来的事实"：类包含关系、基数约束、传递属性一旦登记，机器就能在 SQL 都没生成之前回答"这条查询在这个本体下必然为空"——Ontop 的重写链路里确实有一步空集短路判定，非空的查询才继续往下走（源：01a §6）。
两条源码级证据，说明这一派在今天实际长什么样。
第一条是 Ontop（ontop/ontop，Apache-2.0，953★，默认分支version5），OBDA（Ontology-Based Data Access，用本体当关系库的虚拟视图层）的正典实现。它的映射文件.obda必须是 target/source 两段式：target 写本体侧要生成什么三元组，source 允许是任意一段合法 SQL（视图、UNION、WHERE 切片都行）。查询重写顺序和直觉相反——先用饱和后的 TBox（术语与公理那一层，相对于实例数据 ABox）做重写，再做 mapping unfolding（把本体词换成物理表列），最后才生成原生 SQL，而且所有阶段都跑在同一棵与 SQL 无关的 IQ 中间表示树上（源：01a §6）。这条路线对今天的价值在于：它证明"本体在上、SQL 在下"早就可行，缺的从来不是编译，而是"自然语言 → 本体查询"那一跳。
第二条是 OrionBelt（ralforion/orionbelt-analytics，BUSL-1.1，47★），本次调研十个仓库里唯一真做 RDF/OWL 的问数项目。它的结构映射很朴素：owl:Class对应表、owl:DatatypeProperty对应列、owl:ObjectProperty对应外键关系。值得停下看一眼的是这个设计决定：域值约束用 SHACL 校验，而不是 OWL restriction（源：01a §4）。也就是说，连真做形式本体的团队，都把"跑推理机做一致性检查"换成了"拿形状文件校验本体写没写错"。这是形式本体派自己向工程收敛的一手证据，比任何观点文章都有力。
再说操作型本体派：目标是业务动作闭环。代表是 Palantir Foundry 的 Ontology。主张是本体不止描述数据，还统一对象、关系、动作与权限，并支持写回闭环——Agent 不只查数，还能触发真实业务动作（源：03 §1）。它的可借鉴最小点其实很小：Object Type / Property / Link Type三要素，加上"动作与权限在同一层建模"；开源侧 OntoQuery 已经复刻了这个骨架（源：03 §1）。代价也写得很明白：平台级重投入、封闭生态、按年订阅。
商业化这一支还有另一条分支值得知道：Stardog 走的是 OWL/RDF 知识图谱加推理，主打"无幻觉与确定性校验"，把一致性检查当成一等能力（源：03 §1）——目标偏形式本体，产品形态偏数据访问层。而 Timbr 是本次调研里最贴近 Text2SQL 的中间派：用建本体的方式给语义层建模（把 schema 组织成有继承关系的 T-Box 式结构），同时保持原生 SQL 可查，且明确不追求动作与写回闭环（源：03 §1）。
最后是语义层派：目标就是口径一致地查数。代表是 Snowflake Cortex Analyst 与 Semantic Views、Databricks AI/BI Genie、dbt MetricFlow、Cube（源：03 §1）。这一派的主张可以压成一句：把指标口径前置为受控资产，让 LLM 做"语义匹配"而不是"SQL 生成"。产物是 YAML（或者平台里的元数据配置）加一个确定性的 SQL 编译器。国内的主流形态就是指标平台，也就是第 05、06 篇的主角。
三派并排对照：
| 对照项 | 形式本体派 | 操作型本体派 | 语义层派 |
|---|---|---|---|
| 目标 | 互操作 + 公理推理 | 业务动作闭环 | 口径一致地查数 |
| 核心产物 | TTL、SPARQL、SHACL | Object/Link/Action + 权限 | YAML + SQL 编译器 |
| 查询出口 | SPARQL | 平台 API 与对象视图 | SQL |
| 变更成本 | 高（牵动推理结论） | 平台级（换不动） | 低到中 |
| 本调研拿到的证据 | Ontop、OrionBelt 源码 | 官网与公开文章 | 五套 DSL 一手规范 |
| 什么时候值得 | 需要跨系统语义对齐 | 要把动作写回业务系统 | 只要一个数全公司一致 |
（依据：02 §1 三词划界表、03 §1 国外路线、12 §五 直答）
同一个 GMV，两种写法放在一起，差别就不言自明了。
# 示意（非实测）：形式本体派关心"这条边能不能被机器遍历" # 写法参照 01a §4 的 oba.ttl 真实片段（OrionBelt，BUSL-1.1，不可直接搬用） ns:orders_has_customers a owl:ObjectProperty, owl:FunctionalProperty ; oba:relationshipType "many_to_one" ; oba:sqlJoinCondition "orders.customer_id = customers.id" ; rdfs:domain ns:orders ; rdfs:range ns:customers .# 示意（非实测）：语义层派只关心"这个数怎么算、谁能查"gmv:definition:SUM(pay_amount)filter:"pay_status = 'paid' AND is_deleted = 0"time_role:ordered_at# 时间轴用下单时间，不是支付时间grain:order# 聚合之前每行代表一个订单两段都没有错。但改一次的成本完全不同：前者改一条约束，要重跑一致性检查、确认推理结论没被推翻；后者改一行 YAML，跑一遍校验器和编译回归就能放行（这套门禁在第 03 篇）。变更成本这一栏，才是三派真正的分水岭——不是表达力，不是优雅程度。
⚠️ 未核实：Palantir Foundry、Stardog、Timbr 三家的能力描述（对象/链接/动作与权限同层、OWL 推理与 Safety RAG、SQL 本体层级与继承）全部来自公开文章与官网（源：03 §1），属于厂商宣传口径。本次调研未做任何产品实测，也未在源码层核验；商业产品能力随时变化，选型前请按官方最新文档二次核对。本系列不推销任何产品。
四、三层包含与本系列走哪条路
图 1-2｜读这张图看什么：自上而下是包含关系，不是并列的三件事；右侧三行是责任人与变更成本，两者同步下降——范围越小，改起来越便宜。最下面那行不属于包含关系，它是多数团队真实走过的顺序。
行业里"本体 / 语义层（Semantic Layer）/ 指标层（Metric Layer）"长期混用，导致选型时鸡同鸭讲。目前较被接受的划分如下（源：02 §1）：
| 概念 | 回答什么问题 | 核心产物 | 变更成本 | 谁负责 |
|---|---|---|---|---|
| 本体 Ontology | 业务世界有哪些东西、怎么关联 | 对象/属性/链接类型、约束与规则、同义词表 | 高（牵一发动全身） | 业务 + 数据治理 |
| 语义层 Semantic Layer | 这些东西落在哪张表哪个字段、怎么算 | 逻辑表、度量、维度、join 路径、行级权限 | 中 | 数据团队 |
| 指标层 Metric Layer | 这个月的 GMV 到底是多少 | 指标定义、可加性（additivity）、聚合粒度、口径归属 | 低到中 | 数据 + 业务方共签 |
关系是本体 ⊃ 语义层 ⊃ 指标层：本体管"有哪些东西"，语义层管"落在哪、怎么算"，指标层是语义层的一个特化子集（源：02 §1）。02§1 在指标层那一格写的是"国内主流"——照这个划分法，国内多数团队口中说的"语义层"，实际落在指标层这一格。
但工程上常常反着建。02§1 的原话是：关系上本体 ⊃ 语义层 ⊃ 指标层，“但工程上常常反过来说——先有指标层，再逐步补全本体”。我认为这不是妥协，是经济学：指标层变更成本最低、离业务最近，而它能立刻挡住的错误量级最大。12§五 回答"多快能看到价值"时给的就是这两项——先上默认过滤规则（一行 YAML，本仓库实测避免 +207% 的错），再上 join 禁令（避免 +33%~92%），而且这两项不需要编译器，接在现有 SQL 生成后面当一道事后关卡就能上线（源：12 §五）。
反向建设只有一条必须守的规矩。12§五 第一条直答："顺序无所谓，真相源必须唯一：指标口径归语义层，本体只负责 cardinality / additivity / terms / 治理，两边用导出同步，不允许两处各写一遍 GMV。"一旦两处各写一遍，你得到的将是同一条 GMV 的两个版本各自演化——半年后没人说得清哪个是准的。这正是第 15 篇选型清单里要专门问一句的东西。
这个系列走的路线，一句话说完：以"能挡住错误的最小声明集"为准，不追求完备 OWL（源：12 §五）。落到结构上，是业界已经收敛出的五层参考架构（源：02 §2）：
L5 体验与治理层 ChatBI UI / 归因解释 / 血缘 / 权限 / Eval 门禁 L4 智能体编排层 Multi-Agent / RAG / OAG(操作型增强生成) / 工具调用 / 反思重试 L3 查询编译层 NL → Semantics / Metrics / DSL（受控 IR）→ 确定性编译 SQL + OBQC 校验 L2 语义 / 建模层 ★本体 + 指标语义层 + 物理映射★ —— 准确率的根基 L1 物理数据层 数仓 / Lakehouse / OLTP关键判断只有一句：LLM 只应出现在 L4（理解、规划、消歧）和 L3 的前半段（NL → 受控中间表示，controlled IR）；L3 的 IR→SQL 与 L2 的映射必须是确定性的。一旦让 LLM 直接跨过 L2 去写 SQL，本体就无法保证口径一致（源：02 §2）。这条判断会在第 08 篇用一组对比数字被反复检验。
三条流派在本系列里的取用方式也就清楚了：语义层派的整体骨架（YAML + 确定性编译）是我们的路线；操作型本体派那里，我们只拿"对象、属性、链接三要素 + 权限与语义同层考虑"这一点结构洞见，不拿平台；形式本体派那里，我们拿它的建模纪律（显式、形式化、可校验），不拿推理机。需要公理推理或跨系统语义互操作时，再回头上 OWL——那是第 12 篇讲 Ontop 重写链路时要认真读的部分。
图 1-3｜读这张图看什么：五个模块的颜色就是上面三派的取用分工（M1 划概念、M2 建要素、M3 定 LLM 位置、M4 看别人怎么做、M5 拿证据选型）。01→02→03 是必读前缀，04 到 07 可以各读各的但都依赖 03。
五、本篇依据
本篇全部事实来自以下调研文件（相对本体建模调研/目录），并按证据级别区分：
| 引用标记 | 文件与章节 | 本篇用到的内容 | 级别 |
|---|---|---|---|
| 02 §1 | 02-本体建模方法论与分层框架.md§1 | 三词划界表、包含关系与反向建设 | 一手文献（规范/综述整理） |
| 02 §2 | 同上 §2 | 五层参考架构、LLM 作用域判断 | 一手文献 |
| 02 §3 | 同上 §3 | MVO 五要素、“不追求完备 OWL” | 一手文献 |
| 03 §1 | 03-商业案例与行业实践.md§1 | Palantir/Stardog/Timbr/语义层工业化派主张 | 二手宣传（官网与公开文章，未实测） |
| 12 §五 | 12-选型决策矩阵与路线图.md§五 | 该不该上 OWL、真相源唯一、多快见效 | 本调研判断模型 |
| 05 §5.3 | 05-参考本体设计与编译链路.md§5.3 | 5400/16599（+207.4%）、0%/+38.9%/+91.7% | 实测（DuckDB 受控 seed） |
| 04 轨道 A/B | 04-学习资料与论文.md轨道 A、轨道 B | 四条入门读物清单 | 一手文献导航 |
| 01a §4 | 01a-开源项目代码级剖析.md§4 | OrionBelt 的 OBA 词表与 SHACL 取舍 | 源码级核对 |
| 01a §6 | 同上 §6 | Ontop 的.obda两段式映射与重写顺序 | 源码级核对 |
| 01a §11 | 同上 §11 | 十仓收敛的六层部件、“审核状态必须是机器可查字段” | 本调研归纳 |
| 00 §第 01 篇 | 00-系列大纲与写作规范.md | Gruber 定义与 Studer 四特征 | 教科书式表述，未核实原始出处 |
两处本篇引用的数字，级别说明：+207.4%（5400 对 16599）与+33%~+92%的原始出处是05§5.3 记录的受控实验——本仓库参考实现在 DuckDB 内存库 seed 上跑出，本篇经12§五 转引；读者可自行运行reference-impl/tools/demo_fanout.py复核（Windows 下需先设PYTHONIOENCODING=utf-8）。量级不代表任何生产库。
想亲手感受一下"形式本体派今天实际在做什么"，可以跑一次 OrionBelt 样例头部自带的校验命令（源：01a §4，本次调研只做了源码级核对，未实跑；许可证 BUSL-1.1，允许内部自建使用，不允许嵌入对外产品）：
pyshacl-soba-shacl.ttl-eoba.ttl oba-example.ttl入门读物，从04的轨道 A 与轨道 B 里挑四条，按"能直接用"的程度排（源：04 轨道 A／B）：
- 《Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL》（TKDE 2025 综述），配合同作者的仓库
DEEP-PolyU/Awesome-LLM-based-Text2SQL一起读：论文给方法论，仓库给论文与基准清单。这是本系列轨道 A 的首选入门材料。 - 《本体驱动问数：国内外技术方案深度研究》（中文长文）：本篇第四节那份五层架构清单就是以它的分层为骨架（源：02 §2），想快速建立坐标系读它。
- 《AI 时代本体论-语义网-语义模型-语义层》（博客园短文，标题原文如此）：中文里少见的把四个概念串清楚的一篇，
02§1 与04轨道 B 都推荐它做团队内部分享的开场。 ontop/ontop仓库 + W3C 的 R2RML 规范入口：想认真理解"本体在上、SQL 在下"这条经典路线，绕不开它们（源：04 轨道 B）。
六、小结与下一篇
本篇的三句话：
- "本体"至少指三种东西——形式本体（互操作与推理）、操作型本体（动作闭环）、工程语义层（口径一致地查数）；它们目标、产物、变更成本三者全不同，混用是选型失败的第一现场。
- Gruber/Studer 定义里的四个特征，工程实践只完整保留了 explicit 与 formal 这一半；conceptualisation 被"最小声明集"取代，shared 被换成可审计的状态字段与共签责任人。
- 关系上本体 ⊃ 语义层 ⊃ 指标层，建设顺序常常相反；顺序无所谓，但真相源必须唯一。
下一篇《知识表示的载体谱系：从三元组到 YAML 字段》讲知识表示的载体谱系：同一句"华东的活跃客户 GMV"，在 RDF 三元组、RDFS+OWL 公理、属性图、语义层 YAML 四种载体里分别长成什么样，以及表达力与落地成本这对张力为什么最终会把工程选择推向"最小可执行声明集"。
