本体驱动ERP | Apache Ossie 进孵化器那天，我翻出了 2019 年的本体笔记

7月10号那条消息刷了我几个群：Snowflake 拉着 Databricks、dbt、Salesforce 等 50 多家公司，把 Open Semantic Interchange 送进了 Apache 孵化器，新名字叫 Apache Ossie。

我做的第一件事不是转发新闻。是从硬盘深处翻出 2019 年那份被甲方毙掉的本体方案，看了一遍。

五年前我跟客户说"你们需要一个正式的本体模型来统一业务语义"，对方问"本体是什么？能装到 Hadoop 里吗？"方案毙了。五年后的今天，同一拨人坐在一起定义 YAML 格式的语义标准，而且他们管这叫"Ontology Representation Working Group"。

世界真有意思。

■ Ossie 是什么：不是一个工具，是一份协议

先把话说清楚，免得有人跟我当初一样先入为主。

Ossie 不是一个数据库，不是一个查询引擎，不是你装到生产环境跑的东西。它是一份厂商无关的 YAML/JSON 规范，用来描述"数据是什么意思"。你的 BI 工具读它，知道 MRR 怎么算；你的 AI Agent 读它，知道这个字段叫"客户"而不是"用户"；你的数据治理平台读它，能跟你的数仓对齐业务词汇。

SnowflakeDatabricksdbtAI AgentBI 工具Apache Ossie 语义交换协议数据仓库数据湖业务系统

Ossie 不是中间件，是中间语言——各类工具通过同一份协议"说同一种业务话"

如果你写过 Parquet 文件、用过 Iceberg 表格式、接过 Polaris 目录服务，这套逻辑你应该很熟。数据社区解决碎片化的套路一直没变：不统一工具，统一交换格式。Parquet 统一了文件格式，Iceberg 统一了表格式，Polaris 统一了目录，现在 Ossie 要统一"含义"本身。

一句话总结：Ossie 让"同一个指标，在 Snowflake、Databricks、dbt、BI 工具和 AI Agent 里是同一个数"，而且不需要你手写 N×M 个点对点映射。

■ 他们的"本体表示工作组"，我认真读完了

Ossie 目前有五个工作组。最让我坐不住的，是第四个：Ontology Representation Working Group——本体表示工作组。

你没看错。一个由 Snowflake、Databricks、Salesforce 发起的工业标准，把"本体"写进了工作组名称。我摘一段他们的原话：

"Ossie 目前解决了结构互操作性——任何工具都可以读写通用格式的语义模型——但尚未解决概念互操作性，即不同模型可能用不同名称或结构描述相同的业务概念。本体层将让组织能够独立于数据存储位置，定义规范的业务概念（客户、订单、产品等），并让物理语义模型映射回共享定义。"

翻译成人话：Ossie 不只是"这个字段叫 revenue"，而是要定义"客户"这个概念本身是什么，不管你的 CRM 把它存成 customer、client 还是 account。这事我太熟了——过去五年我一直在用 OWL 干这个。

更让我意外的是，他们的本体模型（在 ontology/ontology.md 里）设计得意外地完整。我拆解一下：

来看一个实际例子——Ossie 的 Person 概念：

ontology:
  - concept: Person
    type: EntityType
    identify_by: [nr]
    relationships:
      - name: nr
        roles:
          - concept: SocialSecurityNr
        verbalizes: ['{Person} is identified by {SocialSecurityNr}']
        multiplicity: OneToOne
      - name: earns
        roles:
          - concept: Salary
        multiplicity: ManyToOne
        verbalizes: ["{Person} earns {Salary}"]

  - concept: Employee
    type: EntityType
    extends: [Person]
    derived_by: ["EXISTS ( Person.earns )"]

如果你写过 OWL，这种"定义类、定义属性、定义约束"的套路太熟了。只不过 Ossie 用的是 YAML，不是 Turtle；用的是 ANSI SQL 表达式，不是 SWRL；用的是 verbalizes 做自然语言标注，不是 rdfs:comment。

■ 体感：行业在从另一个方向爬山，跟我走的是一条路

这是我读完 Ossie 本体规范后最大的感受。

学术界 · OWL/RDF/描述逻辑1970s—现在工业界 · SQL/YAML/dbt/BI语义层2020s—现在← 山巅相遇 →描述逻辑指标口径OWL 2 DL语义层Apache Ossie · 2026

一个很有意思的现象：学术界从逻辑往下走，工业界从需求往上升，在山顶碰上了

2019 年我在项目里推 OWL 本体的时候，甲方最常问的问题是："这玩意儿能直接查数吗？"我说不能——本体是推理用的，不是查询引擎。于是方案毙了。但回头看，他们真正要的不是推理，是 "同一个'活跃客户'不要被三个部门定义成三个口径"。

Ossie 的聪明之处在于：它没有试图解决"推理"问题，它只解决"对齐"问题。它用 YAML 定义概念和关系，用 SQL 表达式做派生规则，用 concept_mappings 把物理表字段映射到业务概念——不碰推理机，不碰描述逻辑，不碰 Pellet、HermiT。整套设计哲学就是：让 80% 的人能上手，不要求他们先学一学期知识工程。

说句公道话。我至今觉得 OWL 的推理表达能力远超 Ossie——OWL 能做 disjointness、能做 cardinality 全约束、能跑 SWRL 规则链，这些 Ossie 全没有。但问题不在这里。问题是：能让五十家竞品公司坐下来签字的，从来不是表达力最强的方案，而是刚好够用、人人能理解、迁移成本最低的方案。

■ 对我们这些做本体的人，三点启示

翻完 Ossie 的 repo 和五个工作组的讨论记录，我整理出三点，每一点都跟我自己的项目直接相关。

第一，本体工程的价值正在被行业重新发现——只是换了个叫法。Ossie 管它叫"概念互操作性"、Palantir 管它叫"Ontology"、Goldman Sachs 的 Legend 管它叫"Data Model"——名字不同，干的是一件事：让机器知道"客户"不是一串 UUID，而是一个有属性、有关系、有约束的实体。如果你过去五年跟我一样被人问"本体有什么用"，接下来的两年你可能不用解释这个了。

第二，不要把 RDF/OWL 当成唯一的输出格式。我去年写的订单本体全是用 Turtle 写的，内部推理非常爽，但跟团队其他工具对接时——dbt 读不了 Turtle，Tableau 读不了 Turtle，AI Agent 也读不了 Turtle。Ossie 的出现说明一件事：本体可以写成 YAML，而且 50 家公司都认。我的建议是：把 OWL 留作推理的"源码"，把 Ossie YAML 当作分发的"编译产物"。这跟写 TypeScript 编译成 JavaScript 是一个逻辑。

我在自己项目里试了一下映射——把订单本体的核心六个类（Order、OrderLine、Product、Customer、Contract、Payment）转成 Ossie 格式，花了不到半小时。输出如下：

# 订单本体 → Ossie 映射示例
ontology:
  - concept: Order
    type: EntityType
    identify_by: [orderNr]
    relationships:
      - name: orderNr
        roles: [{concept: OrderId}]
        multiplicity: OneToOne
        verbalizes: ["{Order} is identified by {OrderId}"]
      - name: belongsTo
        roles: [{concept: Customer}]
        multiplicity: ManyToOne
        verbalizes: ["{Order} belongs to {Customer}"]
      - name: governedBy
        roles: [{concept: Contract}]
        multiplicity: ManyToOne
        verbalizes: ["{Order} is governed by {Contract}"]

第三，赶紧关注这几个 Working Group 的讨论。Ossie 的 Ontology Representation WG 目前正在讨论关系本体（Relational Ontology）和共享语义定义（Shared Semantic Definitions）。这条线的走向会直接影响未来两三年企业数据架构该怎么设计。Discussion #22 和 #101 是两个必读的讨论串，我把链接放在关键词回复里。

■ 坦白说，Ossie 现在还嫩

得说实话。Ossie 目前版本号是 0.2.0.dev0，还在快速迭代。它有几个明显的短板：

HermiT、Pellet 推理机

换句话说：Ossie 是"语义交换层"，不是"语义推理层"。它解决的是"大家说同一种话"，不是"从已知推导未知"。如果需要做本体一致性验证、自动分类、规则推理——该用 Pellet 还是得用 Pellet。

但我觉得这才是最健康的分工。Ossie 管交换和对齐，OWL 管推理和验证。一个负责"大家都认"，一个负责"逻辑严密"。谁也别替代谁。

■ 最后

五年前我拿着一份 OWL 本体方案在会议室里被人问"这个跟 BI 有什么关系"，五年后 BI 厂商自己发了份本体标准。行业没变方向，只是换了一拨人、换了个角度，走进了同一扇门。

如果你做本体工程做了几年，有时候觉得孤单——翻翻 Ossie 的 GitHub repo。50+ 家公司，用 YAML 写"概念-关系-约束"。可能没你写得严谨，但他们带的资金、工程师、用户，个个比你多。

你的团队在用什么管业务语义？dbt metrics？自建本体？还是全靠代码注释？