本篇解决什么把被三方人马同时使用的「本体」这个词拆开让你下次开选型会时能当场指出对方站在哪一派。这是系列开篇无前置篇目。读完能得到一张三派对照表、一条「本体 ⊃ 语义层 ⊃ 指标层」的判据以及本系列为什么不走完备 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.312§五 把它概括为 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 的两段表述是本系列大纲指定的教科书式引用。本次调研的五份素材0203041201a都没有附这两条定义的原始论文年份、期刊与页码所以本文只复述定义内容与四个特征的英文原词不给年份和文献号。需要对外引用时请回到原论文核对。三、三派分岔目标、产物、变更成本图 1-1读这张图看什么横向读一行——同一行的三个框是同一个流派的目标 / 产物 / 代价竖向读是在比较三家谁改得起。发现自己和同事分属不同行那场会就一定吵不完。先说形式本体派目标是互操作与推理。这一支的产物是 TTL SPARQL外加一台描述逻辑推理机Description Logic reasoner把本体写成公理之后能推出你没显式写下的结论。它真正独特的能力就是推出没写出来的事实类包含关系、基数约束、传递属性一旦登记机器就能在 SQL 都没生成之前回答这条查询在这个本体下必然为空——Ontop 的重写链路里确实有一步空集短路判定非空的查询才继续往下走源01a §6。两条源码级证据说明这一派在今天实际长什么样。第一条是 Ontopontop/ontopApache-2.0953★默认分支version5OBDAOntology-Based Data Access用本体当关系库的虚拟视图层的正典实现。它的映射文件.obda必须是 target/source 两段式target 写本体侧要生成什么三元组source 允许是任意一段合法 SQL视图、UNION、WHERE 切片都行。查询重写顺序和直觉相反——先用饱和后的 TBox术语与公理那一层相对于实例数据 ABox做重写再做 mapping unfolding把本体词换成物理表列最后才生成原生 SQL而且所有阶段都跑在同一棵与 SQL 无关的 IQ 中间表示树上源01a §6。这条路线对今天的价值在于它证明本体在上、SQL 在下早就可行缺的从来不是编译而是自然语言 → 本体查询那一跳。第二条是 OrionBeltralforion/orionbelt-analyticsBUSL-1.147★本次调研十个仓库里唯一真做 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、SHACLObject/Link/Action 权限YAML SQL 编译器查询出口SPARQL平台 API 与对象视图SQL变更成本高牵动推理结论平台级换不动低到中本调研拿到的证据Ontop、OrionBelt 源码官网与公开文章五套 DSL 一手规范什么时候值得需要跨系统语义对齐要把动作写回业务系统只要一个数全公司一致依据02 §1 三词划界表、03 §1 国外路线、12 §五 直答同一个 GMV两种写法放在一起差别就不言自明了。# 示意非实测形式本体派关心这条边能不能被机器遍历 # 写法参照 01a §4 的 oba.ttl 真实片段OrionBeltBUSL-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 0time_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 §2L5 体验与治理层 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 IRL3 的 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 §102-本体建模方法论与分层框架.md§1三词划界表、包含关系与反向建设一手文献规范/综述整理02 §2同上 §2五层参考架构、LLM 作用域判断一手文献02 §3同上 §3MVO 五要素、“不追求完备 OWL”一手文献03 §103-商业案例与行业实践.md§1Palantir/Stardog/Timbr/语义层工业化派主张二手宣传官网与公开文章未实测12 §五12-选型决策矩阵与路线图.md§五该不该上 OWL、真相源唯一、多快见效本调研判断模型05 §5.305-参考本体设计与编译链路.md§5.35400/16599207.4%、0%/38.9%/91.7%实测DuckDB 受控 seed04 轨道 A/B04-学习资料与论文.md轨道 A、轨道 B四条入门读物清单一手文献导航01a §401a-开源项目代码级剖析.md§4OrionBelt 的 OBA 词表与 SHACL 取舍源码级核对01a §6同上 §6Ontop 的.obda两段式映射与重写顺序源码级核对01a §11同上 §11十仓收敛的六层部件、“审核状态必须是机器可查字段”本调研归纳00 §第 01 篇00-系列大纲与写作规范.mdGruber 定义与 Studer 四特征教科书式表述未核实原始出处两处本篇引用的数字级别说明207.4%5400 对 16599与33%~92%的原始出处是05§5.3 记录的受控实验——本仓库参考实现在 DuckDB 内存库 seed 上跑出本篇经12§五 转引读者可自行运行reference-impl/tools/demo_fanout.py复核Windows 下需先设PYTHONIOENCODINGutf-8。量级不代表任何生产库。想亲手感受一下形式本体派今天实际在做什么可以跑一次 OrionBelt 样例头部自带的校验命令源01a §4本次调研只做了源码级核对未实跑许可证 BUSL-1.1允许内部自建使用不允许嵌入对外产品pyshacl-soba-shacl.ttl-eoba.ttl oba-example.ttl入门读物从04的轨道 A 与轨道 B 里挑四条按能直接用的程度排源04 轨道 AB《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 三元组、RDFSOWL 公理、属性图、语义层 YAML 四种载体里分别长成什么样以及表达力与落地成本这对张力为什么最终会把工程选择推向最小可执行声明集。