采购人员提出：“请找出华东工厂现在可以买到的 24V 控制器，最好还有替代品。”上一篇已经把这句话拆成了输入、预期结果和失败条件。接下来还有一个容易被低估的问题：这件事究竟应该交给哪一种语义技术？
如果把五种标准都当成“图数据库功能”，团队很快会遇到混乱：有人用查询语句做数据校验，有人期待类层次自动给出推荐，还有人把没有记录当成事实为假。RDF、RDFS、OWL、SPARQL 和 SHACL 经常一起出现，但它们承担的工作并不相同。
业务场景：同一个问题需要五种视角
我们的合成供应链数据来自产品目录、供应商合同和工厂地点。产品目录说某个产品是“控制器”，合同记录供应商与地点的供货关系，业务人员还希望查询“可替代品”。这些信息可能来自不同系统，字段名称和更新时间也不一致。
单靠一张关系表，很难同时表达以下事实： 产品属于哪个类别，某个属性适用于哪一类资源，两个类别是否等价，哪些事实可以从已有陈述推得，哪些记录违反数据质量约束，以及如何按日期查询有效关系。五项标准可以共同参与同一条流水线，但每一项都只解决其中一部分问题。
五项标准不是五选一
先看一张适合工程评审的映射表。表中的“主要负责”表示最适合交付给它的工作，不表示其他技术完全不能参与。
供应链问题 |
主要负责的标准 |
得到的结果 |
不应期待的结果 |
|---|---|---|---|
| 怎样记录产品、地点和供货关系 | RDF | 可交换的三元组和 RDF 图 | 自动判断事实是否完整或正确 |
| “控制器”是不是“产品”的子类，属性适用于什么资源 | RDFS | 类、属性及其基本语义，可推导的类型 | 把缺少字段当成校验失败 |
| 两类产品是否等价、互斥，或某关系具有什么逻辑特性 | OWL | 更丰富的本体公理和推理结论 | 像表单一样强制所有字段存在 |
| 给定地点、日期和合同，返回可采购产品 | SPARQL | 查询结果、构造图或受控更新 | 自动证明本体一致或替数据补齐证据 |
| 产品必须有分类、合同关系的日期格式是否正确 | SHACL | 通过或失败的验证报告 | 把验证报告当成 OWL 推理结论 |
一条成熟流程往往会把它们组合起来：先用 RDF 交换事实，用 RDFS 或 OWL 解释语义，再用 SHACL 检查数据是否满足项目约束，最后用 SPARQL 提供面向业务的问题答案。具体先后顺序要根据项目定义，例如验证原始图还是验证推理后的图，不能凭工具名称猜测。
RDFS 和 OWL 的本体陈述、SHACL 的形状本身也可以用 RDF 图表示。它们采用相同的图数据模型，并不意味着承担相同的任务：就像配置文件和业务数据都可以写成 JSON，但程序不会因此把两者当成一种内容。
RDF：把事实放进一张图
资源描述框架（Resource Deion Framework，RDF）首先是一种数据模型。一个 RDF 图由三元组组成：主语、谓语和宾语。主语通常使用国际化资源标识符（Internationalized Resource Identifier，IRI）稳定标识资源，谓语使用 IRI 标识关系，宾语可以是另一个资源，也可以是带数据类型或语言标签的字面量。
为避免提前引入下一篇才会解释的 Turtle 语法，先用可读形式展示三条合成事实：
产品-1001 类型 控制器 产品-1001 额定电压 24V 产品-1001 可供货地点 华东工厂
这里的重点是“如何表示”，而不是“事实是否正确”。RDF 不会因为谓语叫“类型”就自动检查对象是不是一个类别，也不会因为没有“合同”三元组就断定产品不能采购。RDF 图可以承载业务事实，也可以承载本体定义；仅采用 RDF 数据模型，并不自动成为经过身份、来源和质量治理的知识图谱。
RDF 还定义了数据集和命名图的表示方式。命名图可以帮助我们区分来源或版本，但它本身不替业务声明“这个图就是某个部门的数据”。来源、权限和有效期仍需要明确建模和治理。
RDFS：给类和属性增加基础语义
RDF 模式（RDF Schema，RDFS）提供一组轻量的类和属性词汇。例如，rdfs:subClassOf表示子类关系，rdfs:subPropertyOf表示子属性关系，rdfs:domain和 rdfs:range分别描述属性两端资源的语义类型。
假设本体声明“控制器是产品的子类”，数据中有：
产品-1001 rdf:type 控制器 控制器 rdfs:subClassOf 产品
在启用 RDFS 语义解释后，可以推出产品-1001 也是产品。这是语义蕴含，不是把一条记录写入数据库的字段校验。
domain和 range尤其容易被误解。若声明“供货地点的范围是地点”，当数据出现“关系-7 供货地点 华东工厂”时，解释器可以据此把华东工厂视为地点。它不是在输入阶段检查“华东工厂”是否填写，也不是在值为空时生成错误报告。需要必填、格式和枚举校验，应交给应用约束或 SHACL。
RDFS 适合先建立可复用的类层次和属性语义。它的表达能力有意保持轻量，不能替代 OWL 对等价、互斥、限制和复杂属性特征的表达。
OWL：表达更丰富的本体语义
网络本体语言（Web Ontology Language，OWL）在 RDFS 基础上提供更丰富的公理。例如，可以声明两个类等价或不相交，可以声明属性的逆关系、传递性或对称性，也可以描述“一个供货关系至少关联一个合同”这样的存在限制。
OWL 需要特别记住两条语义前提。
第一，OWL 采用开放世界假设（Open-world assumption，OWA）。图中没有记录某产品的合同，不代表产品没有合同，只说明当前知识不足以证明它有合同。第二，OWL 不采用唯一名称假设（Unique name assumption，UNA）。两个不同的 IRI 不必然代表两个不同实体；只有在模型或数据中明确表达身份差异时，才能作出相应判断。
因此，OWL 推理适合回答“根据公理还能推出什么”，不适合单独承担“提交表单时合同字段必须存在”。如果采购流程需要在缺合同事实时阻止提交，应使用 SHACL 或业务服务规则；如果需要在证据不足时返回“无法判断”，则要在查询和接口契约中明确这种状态。
OWL 也不是一个单一的“开启即完成”功能。不同推理器支持的 OWL 2 语言子集（profile）、规则范围和错误解释能力可能不同。工程上应记录输入本体、推理配置、工具版本和期望派生结论，不能把某次推理器运行结果泛化成所有 OWL 工具都能得到的结果。
SPARQL：把可验证问题变成查询
SPARQL Protocol and RDF Query Language（SPARQL）是面向 RDF 的查询和更新语言。它可以用 SELECT返回表格结果，用 ASK判断图模式是否存在，用 CONSTRUCT生成新的 RDF 图，也可以在受控边界内执行更新。
以“给定地点和日期返回可采购产品”为例，SPARQL 负责描述要匹配的图模式、筛选日期和投影结果字段。它可以查询已经物化的推理结果，也可以连接一个配置为查询时推理的服务，但“是否启用推理”是执行环境的明确配置，不是 SELECT关键字自带的行为。
SPARQL 查询结果也不是完整性证明。查询返回空集，可能表示确实没有匹配事实，也可能是来源尚未接入、权限过滤或日期条件不正确。要区分“没有”“未知”和“无权查看”，接口必须设计状态字段和来源信息，而不能只返回一个布尔值。
在 .NET 服务中，查询结构应使用模板和允许列表，用户值作为参数绑定或经过严格转义。尤其要把读取查询和非幂等更新分开，设置超时、取消和复杂度限制，并记录查询版本。下一阶段实战 SPARQL 时再固定具体 API 和包版本。
SHACL：验证数据是否符合项目约束
形状约束语言（Shapes Constraint Language，SHACL）用形状（Shape）描述数据应满足的条件。例如，产品节点必须有且只有一个产品分类，额定电压必须是数值，供货关系必须带有效起止日期。验证器根据数据图和形状图生成验证报告，报告中可以指出违反约束的节点、路径、消息和严重级别。
SHACL 的“失败”与 OWL 的“推不出来”不是同一种结果。SHACL 通常按项目要求检查当前提交的数据，适合回答“这批数据能否进入知识服务”。如果产品没有合同关系，SHACL 可以把它报告为违规；OWL 在开放世界下不会仅因缺少关系就推出“没有合同”。
形状也不等于数据库表结构。SHACL 约束的是 RDF 图上的节点和路径，可以用于跨来源数据的统一入口；但它不会自动开启事务、修复数据或替业务系统决定是否允许下单。验证报告需要被流水线、隔离区和人工复核流程真正消费，才会产生工程价值。
用一条供应链问题走完整流程
现在回到上一篇的 CQ-04：“给定产品、地点、采购日期和采购组织，返回有效供货关系、合同依据和来源；若证据不足，返回无法判断。”可以把它拆成以下步骤：
- 表示
用 RDF 记录产品、组织、地点、合同、供货关系、来源和有效期。
- 解释
用 RDFS 表示产品和控制器的类层次；需要等价、互斥或属性限制时再用 OWL。
- 验证
用 SHACL 检查产品分类、合同编号、日期类型和供货关系的必要结构。验证失败的数据进入隔离区，不直接参与采购判断。
- 查询
用 SPARQL 按采购日期筛选有效关系，返回合同依据、来源和判断状态。
- 解释结果
服务将“有证据可采购”“没有匹配事实”“证据不足”“无权查看”区分开，避免把空结果包装成肯定或否定结论。
这条流程没有把五项标准排成固定的技术排行榜。它只说明每一项在问题链路中承担不同职责：RDF 保留事实，RDFS 和 OWL 提供语义，SHACL 做质量门禁，SPARQL 面向问题取数。
常见混淆：用错误工具回答正确问题
把 RDF 当成知识图谱。RDF 只是图数据模型。没有身份、来源、版本、质量和服务能力，一批三元组仍可能只是交换数据。
把 domain和 range当字段校验。它们可以参与类型推断，不会在写入时替你报告缺失或格式错误。
把 OWL 当成业务规则引擎。OWL 的公理有明确的模型理论语义；审批、库存锁定、权限和事务需要业务服务或规则系统。
把 SPARQL 空结果当成“不存在”。查询只说明在给定数据集、图范围、权限和条件下没有匹配结果。开放世界下还要考虑信息缺失。
把 SHACL 报告当成推理结果。“数据不符合形状”是约束验证结论，不等于“本体推出了一个新事实”。两者应分别记录、测试和解释。
在.NET 工程中如何划分边界
在 .NET 项目中，可以把五项标准看成不同的接口边界，而不是五个互相竞争的 NuGet 包：
RDF 读写层负责解析、序列化和图合并。
RDFS、OWL 推理层负责按明确的 profile 或规则产生派生图。
SPARQL 访问层负责查询模板、参数、超时、取消和结果映射。
SHACL 验证层负责加载形状、运行验证并保存机器可读报告。
业务服务层负责权限、事务、采购状态和“证据不足”等业务状态。
系列后续会以 dotNetRDF 等 .NET 组件处理 RDF 和 SPARQL 的核心工作，并通过标准文件、CLI、容器或 HTTP 边界接入复杂推理和验证能力。具体组件版本和支持范围必须以对应文章的实测为准。把所有语义能力都塞进一个应用服务，会让版本升级、失败定位和替代工具变得困难。
五项断言自测
请判断下面每个说法主要属于哪项标准，或指出它不应由这五项标准单独承担：
把“产品-1001 在华东工厂供货”表示成可交换的三元组。
根据“控制器是产品的子类”，推出某个控制器也是产品。
判断“产品没有合同三元组”是否足以证明它不能采购。
查询某日期内有效的供货关系，并返回合同和来源。
检查每个供货关系是否带起止日期，日期是否能解析为明确类型。
事务回滚、权限审批和库存锁定应由哪一层负责。
查询返回空集时，如何区分没有匹配、资料未接入和无权查看。
用两个不同 IRI 推断两个资源一定是两个实体，是否成立。
参考判断：1 是 RDF；2 是 RDFS 语义推断；3 不能由 OWL 单独完成，开放世界下缺失通常是未知；4 是 SPARQL；5 是 SHACL；6 应由业务服务、数据库或权限系统负责；7 应由查询条件、来源和接口状态共同表达；8 不成立，OWL 不采用唯一名称假设。
如果能把前五题分别映射到 RDF、RDFS、OWL 边界、SPARQL 和 SHACL，并解释第 6 至第 8 题的责任归属，就完成了本文的验收。
生产注意事项：标准边界必须写进运行配置
同一个 SPARQL 查询，在是否启用推理、查询默认图、权限过滤和数据版本不同的情况下，结果可能不同。生产系统必须记录数据集范围、推理范围、形状版本、查询版本和验证时间；否则出现“昨天能查到、今天查不到”时，很难判断是事实变化还是执行配置变化。
还要为失败结果保留可解释信息：SHACL 报告保留违规路径，查询结果保留来源和有效期，推理任务保留派生规则和工具版本。远程端点则需要超时、限流和查询复杂度控制，避免把开放查询入口变成资源消耗点。返回搜狐，查看更多