Ontology 学习 二

参考：一文读懂 Ontology：连接数据、业务与 AI 的关键语义层

一文读懂 Ontology 背后的四大技术：RDF、OWL、SPARQL、SHACL

用 Ontology 为 AI 提供更准确、更统一的业务上下文。

大模型虽然能够理解自然语言，却未必真正理解企业中的"客户、订单、产品、工厂"分别代表什么，它们之间又存在怎样的业务关系。

把Ontology（本体） 想象成企业数据世界的"通用字典"，或者一张描述现实业务的"高维地图"。

Ontology 的作用，就是抹平"机器数据"与"人类业务"之间的鸿沟。

它用计算机能够理解的方式，把现实业务中的概念以及概念之间的关系组织成一张网络，让人类、数据系统和 AI 都能以统一的业务视角理解和使用数据。

Ontology 的四个核心概念

在计算机科学和数据本体中，Ontology 通常由以下四个核心概念构成。

1. 实体类型（Entity Type）：业务中的"名词"

• **通俗理解：**业务世界中的概念分类，相当于一套模板。

• **举例：**客户、产品、订单、工厂、传感器。

• 作用:

  不论 CRM 系统中叫 Cust_Name，还是 ERP 系统中叫 Client_Title，在本体中都可以统一归纳为"客户"，从而减少不同系统之间的命名混乱。

简单来说，实体类型定义了业务世界中"有哪些东西"。

2. 实体实例（Entity Instance）：具体的业务对象

• **通俗理解：**基于实体类型产生的一个个具体对象。
• 举例：
  • 实体类型是"客户"，实体实例可以是"张三"。
  • 实体类型是"产品"，实体实例可以是"编号为 A102 的手机"。

可以理解为

|------------------------------|
| 实体类型表示"这是什么"，实体实例表示"具体是哪一个"。 |

3. 属性（Property）：对象的特征

• **通俗理解：**用来描述实体的具体信息或状态。
• 举例：
  • "客户"的属性：姓名、电子邮箱、注册时间。
  • "传感器"的属性：温度、实时电压、运行状态。

属性让计算机能够更完整地描述一个业务对象。

4. 关系（Relation）：对象之间的连接

• 通俗理解：实体与实体之间的逻辑纽带，相当于业务世界中的"动词"。
• 举例：
  • 客户 ------下单------> 订单
  • 工厂 ------生产------> 产品

关系本身还可以包含业务规则，例如一个客户可以对应多个订单。

原本孤立的数据点就能连接成一张业务网络。AI 或数据分析人员也不必每次都从复杂的多表关联开始，而是可以沿着明确的业务关系进行查询和追溯。

|---------------------|------------------------------------------------------|
| 概念 | 通俗解释 |
| 数据绑定（Data Binding） | 像一个"插线板"，把"客户""订单"等业务概念，与数据库、数据湖、业务系统或 API 实时数据连接起来。 |
| 本体图（Ontology Graph） | 像一张"业务地图"。节点是具体对象，例如张三；边是对象之间的关系，例如张三购买了某款手机。 |

数据绑定完成后，原本分散在不同系统和数据表中的信息，就会形成一张统一的业务知识网络。

使用者可以通过图查询语言进行查询，也可以直接使用自然语言提问。

但到了 AI 时代，大模型和 AI Agent 需要理解的，不只是数据结构，更是业务逻辑。

有了 Ontology：

• 业务人员

  可以直接提问："找出本月购买过缺陷产品的客户。"

• AI Agent

  可以理解客户、订单、产品和工厂之间的关系，再根据统一的业务语义进行查询、推理和操作。

Ontology 还能减少 AI 因字段命名混乱、表结构变化或关联关系不清而产生的错误。

换句话说，Ontology 为 AI 提供的并不只是一份数据说明书，而是一套相对完整的"业务认知框架"。

它让计算机不只是存储数据，而是进一步理解业务，也正在成为连接企业数据与 AI Agent 的关键基础。

简单来说， Ontology 通过实体、属性和关系，把数据库中的表、字段和记录，转换为客户、订单、产品、工厂等业务概念， 让计算机不仅能够找到数据，还能理解数据代表什么、彼此之间有什么关系 。

RDF、OWL、SPARQL 和 SHACL。

• RDF 负责 表示和连接数据 ；
• OWL 负责 定义概念与语义 ；
• SPARQL 负责 查询和操作数据 ；
• SHACL 负责 检查数据是否符合要求 。

Ontology 要解决的问题，就是在底层数据和现实业务之间，建立一层统一的语义模型。

|--------|--------------|
| 技术 | 主要作用 |
| RDF | 把数据表示成可以连接的图 |
| OWL | 定义概念、关系和逻辑含义 |
| SPARQL | 查询和操作图中的数据 |
| SHACL | 检查数据是否符合业务要求 |

RDF：把数据连接成一张图

RDF 的全称是 Resource Description Framework ，中文通常翻译为" 资源描述框架 "。

它最核心的思想，是使用下面这种结构描述一条事实：

主语------谓语------宾语

例如：

• 张三------提交------订单 1001
• 订单 1001------包含------订单项 01
• 订单项 01------对应------手机 A102
• 苏州一号工厂------生产------手机 A102

每一条这样的描述，都叫作一个 三元组 。

用 RDF 常见的 Turtle 语法表示，大致是这样：

ex:zhangsan ex:places ex:order1001 .

RDF 更关心 ：

• 这是什么对象；
• 它和谁有关；
• 它们之间是什么关系。

因此，RDF 很适合用来整合不同系统中的客户、订单、产品、工厂和设备等数据。

在实际建模中，订单通常不会直接连接产品，而是通过"订单项"连接。

因为购买数量、单价、折扣和批次等信息，既不完全属于订单，也不完全属于产品，而是属于"这一次购买行为"。

因此，更合理的关系是：

客户 → 订单 → 订单项 → 产品 ← 工厂

当一段关系本身还具有属性时，应当把它建模为一个独立实体。

OWL：让计算机理解概念的含义

RDF 可以把数据连接起来，但它本身并不知道这些数据背后的业务含义。

例如，RDF 可以记录：

张三是 VIP 客户。

但它并不知道：

VIP 客户也是客户。

这时就需要 OWL。

OWL 的全称是 Web Ontology Language ，主要用于定义：

• 类和子类；
• 属性和关系；
• 等价概念；
• 互斥概念；
• 逆向关系；
• 基数和逻辑限制。

OWL 可以理解为企业数据世界中的：

概念体系、业务词典和逻辑说明书。

它不仅描述数据之间"连着什么"，还进一步说明这些概念和关系"意味着什么"。

SPARQL：按业务关系查询数据

数据被组织成 RDF 图以后，还需要一种查询语言。

这就是 SPARQL。

SPARQL 是 RDF 图数据的标准查询语言。它和 SQL 有些相似，但查询思路并不完全一样。

SQL 通常围绕表和字段进行查询，例如：

• 查询客户表；
• 关联订单表；
• 再关联订单项表和产品表。

SPARQL 则更关注需要匹配的对象和关系路径。

SELECT ?customer ?product

WHERE {

?customer ex:places ?order .

?order ex:contains ?line .

?line ex:item ?product .

}

它描述的不是具体表名，而是一条业务关系：

客户 → 订单 → 订单项 → 产品

因此，使用者首先考虑的是"业务上要查什么关系"，而不是"数据究竟位于哪几张表中"。

除了普通查询，SPARQL 还支持：

• 条件过滤；
• 数据聚合；
• 多跳关系查询；
• 构造新的图数据；
• 更新 RDF 图；
• 跨多个知识图谱进行联邦查询。

对于 AI Agent 来说，SPARQL 也可以成为访问企业语义数据的一种标准接口。

Agent 不必直接理解所有底层数据库结构，而可以按照 Ontology 中定义的业务概念和关系查询数据。

OWL 负责描述概念和逻辑，但企业系统还需要检查真实数据是否合格。

例如，一条订单数据可能必须满足：

• 必须有订单号；
• 必须关联一个客户；
• 至少包含一个订单项；
• 订单日期必须是日期类型；
• 订单状态只能使用规定值。

这些规则适合使用 SHACL 来定义。

SHACL 的全称是 Shapes Constraint Language ，可以理解为 RDF 数据的质量检查语言。

当一批数据进入知识图谱时，SHACL 可以自动检查：

• 哪条数据存在问题；
• 哪个属性缺失；
• 数据类型是否正确；
• 关联对象是否符合要求；
• 违反了哪条业务规则。

例如，我们可以要求一条订单数据：

订单号：必须存在，而且只能有一个

客户：必须关联一个 Customer

订单项：至少存在一个

如果某条订单缺少客户，或者订单日期不是正确的日期类型，SHACL 就可以生成验证报告，明确指出问题所在。

SHACL 很像 RDF 世界中的：

• 数据校验器；
• 接口数据契约；
• Schema 约束；
• 数据质量门禁。

它通常会被放在数据导入、API 接入、知识图谱发布和 CI/CD 流程中。

OWL 负责判断"什么在逻辑上成立"，SHACL 负责检查"这批数据是否符合交付要求"。

我们在 OWL 中定义：

每个订单恰好由一个客户提交。

如果某条订单数据暂时没有写明客户，OWL 不一定会直接认为它是错误数据。

这是因为 OWL 主要采用：

开放世界假设（Open World Assumption，OWA）

开放世界假设认为：

数据中没有出现的信息，不代表它不存在，也可能只是暂时未知。

但企业数据治理通常需要一种更严格的验收方式：

当前提交的这批数据中，每条订单都必须明确包含客户。

这种工程思路更接近：

封闭世界假设（Closed World Assumption，CWA）

也就是把当前能够看到的数据视为验收范围：没有提供，就按照缺失处理。

SHACL 的数据验证方式，在实际工程中更接近这种封闭式的数据验收思路。

因此：

• OWL 更偏向语义、逻辑和推理；
• SHACL 更偏向数据质量、约束和验收。

四项技术如何协同工作？

在一个完整的 Ontology 系统中，四项技术通常按照下面的方式协作。

第一步：接入原始数据

数据可能来自：

• 关系数据库；
• Excel、CSV；
• JSON API；
• 业务事件流。

第二步：转换为 RDF

将原来的表、字段和记录，转换为统一的：

• 实体；
• 属性；
• 关系；
• 三元组。

第三步：使用 SHACL 做入口验证

先检查：

• 必填字段；
• 数据类型；
• 引用关系；
• 数据格式。

明显不合格的数据，不应该直接进入知识图谱，而可以进入隔离区等待处理。

第四步：使用 OWL 进行语义推理

根据类层次、逆向关系和其他逻辑规则，推导出新的业务事实。

例如：

• 根据"VIP 客户属于客户"，推导张三也是客户；
• 根据"生产"和"由......生产"互为逆关系，补充反向关系；
• 根据产品分类体系，推导产品所属的上级类别。

第五步：再次执行 SHACL 验证

部分问题只有在推理后才能发现。

因此，可以对推理后的数据再次执行验证，检查派生结果是否符合发布要求。

第六步：通过 SPARQL 提供查询服务

最终把知识图谱提供给：

• 搜索系统；
• BI 平台；
• API 服务；
• 推荐系统；
• AI Agent。

完整流程可以概括为：

数据源 → RDF → SHACL 入口验证 → OWL 推理 → SHACL 结果复核 → SPARQL 查询 → AI 应用

更稳妥的做法，是先确定系统必须回答的问题，例如：

• 哪些客户购买过缺陷产品？
• 某批产品由哪些工厂生产？
• 哪些订单受到产品召回影响？
• 某台设备关联了哪些维修记录？

这类问题在本体工程中通常被称为：

Competency Questions，能力问题或能力验证问题。

先明确系统必须回答什么，再反推需要哪些实体、属性和关系。

试点阶段只需要覆盖：

• 少量核心业务实体；
• 一两个真实数据源；
• 几个高价值查询；
• 一组关键数据校验规则。

先完成一个：

建模 → 接入 → 验证 → 推理 → 查询 → 应用

的小闭环，再逐步扩展到更多业务领域。

生产级 Ontology 也不只是一个 .owl 文件，而是一套由语义模型、数据映射、验证规则、查询服务、版本管理和治理流程共同组成的工程系统。

再次总结：

• RDF ：把事实连接起来；
• OWL ：把语义定义清楚；
• SPARQL ：把需要的数据查出来；
• SHACL ：确保数据符合要求。