SHACL：把数据治理规则变成可执行的校验

一条员工数据进入知识图谱：姓名、工号、所属部门都在，岗位也已经和组织结构连接起来。推理机能够判断他是一名员工，能够沿着上下级关系找到他的部门，甚至可以根据岗位类别推导出他属于技术序列。

但这条数据仍然可能不能用。工号可能填了两个，邮箱只是一个普通字符串，所属部门指向了已经停用的组织。更麻烦的是，这名员工已经离职，图中却还挂着一条有效的管理员授权。

上一篇介绍的 RDF、RDFS 和 OWL，主要解决事实如何表达、概念如何定义以及知识如何推理。但企业真正把这些知识接入系统后，还会遇到另一个很实际的问题：进入系统的数据，是否符合已经约定好的业务规则和质量要求？

这正是 SHACL 要处理的问题。

OWL 可以声明“架构师是员工的一种”，也可以描述“正式员工与外部供应商互不相交”。如果某个对象被标记为架构师，推理机可以进一步得到它也是员工；如果一个对象同时落入两个互斥类别，推理过程也可以暴露知识库中的逻辑冲突。

但数据治理中的许多要求并不属于这类逻辑公理。

企业可能规定，每名员工必须填写一个工号，邮箱必须符合指定格式，入职日期必须使用日期类型，所属组织必须指向当前组织目录中的有效节点。到了权限数据，要求往往更加具体：临时授权必须填写失效时间，高风险操作必须关联审批记录，离职人员不得继续持有生效中的权限。

这些规则关注的是当前提交的数据是否符合预期。

SHACL，全称 Shapes Constraint Language，是用于描述 RDF 图约束的一套语言。它通过 Shape 定义数据应该满足的结构和规则，再由 SHACL 处理器检查实际数据，并生成结构化的验证结果。

为了便于理解，可以把几层技术的分工粗略概括为：

RDF 记录事实，OWL 描述和解释事实，SHACL 检查事实是否符合约定。

三者解决的问题不同，也恰好对应了企业知识图谱落地时经常同时面对的几类需求。

一次 SHACL 验证通常涉及两个主要输入。

第一个是 Data Graph，也就是待检查的 RDF 数据；第二个是 Shapes Graph，其中保存需要检查哪些对象，以及这些对象应该满足什么条件。SHACL 处理器把数据和规则放在一起执行验证，最终产生 Validation Report。

Shape 本身并不是一个业务对象，更接近一份可以执行的数据规格。例如下面这段 Turtle，要求所有 ex:Employee 类型的节点都必须具有一个，并且只能具有一个字符串类型的员工编号。

sh:targetClass 先选出需要检查的节点，这些节点被称为焦点节点；sh:path 指向需要检查的属性路径；sh:minCount、sh:maxCount 和 sh:datatype 则分别规定属性数量和数据类型。理解一条 Shape，通常可以看三个问题：检查谁，沿哪条路径检查，什么结果才算合格。

这里还需要区分“一个员工只能填写一个工号”和“所有员工的工号不能重复”。

上面的 sh:minCount 1 与 sh:maxCount 1 约束的是单个员工节点的属性数量，只能保证每名员工恰好存在一个 employeeId 值，并不能直接保证不同员工之间没有使用同一个工号。如果业务要求工号在整个员工集合中保持唯一，还需要增加跨节点的唯一性检查，复杂场景可以通过 SPARQL-based constraint 等方式表达。

除了按类别选择目标，SHACL 还可以指定具体节点，或者根据某个属性的主体、客体确定需要检查的数据。这样，规则不必每次都扫描整张图，可以围绕实际的数据对象和治理范围来组织。

初次接触 SHACL 时，一个很自然的问题是：OWL 已经可以描述基数、类型和类限制，为什么还需要另一套约束语言？

关键差别在于两者的判断方式。

OWL 通常采用开放世界的语义。知识库中没有出现某条事实，一般只能说明系统目前不知道这件事，并不能直接认定事实不存在。

假设图中没有记录张三的邮箱，OWL 不会因为缺少这个三元组就断言“张三没有邮箱”。这个信息可能还存在于尚未接入的数据源中。对于持续接入、不断扩展的企业知识来说，这种语义很重要。

SHACL 处理的是当前交给验证器的数据图。如果 Shape 规定邮箱的 sh:minCount 为 1，而当前数据中没有找到邮箱，就会产生一条验证结果。验证器不需要判断现实世界中是否还存在一个未知邮箱，它只负责判断：这次提交的数据是否符合当前规则。

两者对于一些看起来相似的声明，也可能产生完全不同的效果。

在 RDFS 或 OWL 中，为属性声明定义域，通常用于支持类型推断，并不等于禁止其他类型的节点使用这个属性；而在 SHACL 中，如果规则明确要求某个属性值属于指定类别，验证器会直接检查当前数据是否满足要求。

前者用于补充和解释知识，后者用于检查数据。

因此，在企业知识系统中，更稳妥的组合方式是让 OWL 表达领域中相对稳定的概念、关系和公理，让 SHACL 承担具体数据流程中的质量要求和约束规则。

还有一个容易忽略的问题：SHACL 验证时是否使用推理结果，需要在系统设计中明确。数据是先经过 RDFS、OWL 推理再交给 SHACL，还是直接对原始数据图执行验证，会影响最终结果。实际系统需要把这一点作为验证流程的一部分，而不能默认所有处理器都会自动完成完整推理。

SHACL Core 已经能够覆盖不少常见的数据质量问题。

最基础的是属性数量、类型和格式。sh:minCount、sh:maxCount 可以检查必填和属性数量；sh:datatype 用于检查数据类型；sh:pattern 可以处理编码、邮箱等格式；sh:in 可以把属性限制在一组允许的状态值中。

图数据更重要的特点在于关系，因此 SHACL 的检查范围也可以继续沿关系扩展。例如，从员工节点沿“所属组织”关系找到组织，再检查这个组织是否处于有效状态；也可以要求某个关联对象继续满足另一组 Shape。对于多条属性之间的关系，还可以通过相应的约束组件比较不同路径上的值。

在企业数据治理中，可以大致把常见需求与 SHACL 能力对应起来：

例如，企业可以规定一个外部账号必须关联供应商或合作伙伴，并且两种身份只能出现一种；也可以沿着员工与组织之间的关系继续检查，确认员工当前关联的是有效组织。

对于结构必须严格固定的数据交换场景，还可以使用封闭 Shape，对未声明的额外属性进行限制。

不过，封闭校验并不适合无差别使用。知识图谱本身经常会随着业务发展增加新的属性。如果所有 Shape 都采用严格封闭策略，一次正常的模型扩展就可能制造大量误报。是否允许额外属性，应该由数据交换边界、消费方要求和治理责任共同决定。

当常规约束组件难以表达复杂的跨节点条件时，可以继续使用 SPARQL-based constraint 扩展表达能力。代价也很直接：规则越复杂，维护、执行和排查成本越高。能通过声明式约束解决的问题，通常没有必要一开始就写成复杂查询。

如果一个验证系统最后只告诉你“通过”或者“不通过”，它与普通接口校验的区别并不会很大。

SHACL 更适合进入数据治理流程的一点，是验证结果能够结构化表达具体问题。

Validation Report 可以记录整张数据图是否通过验证，也可以针对每个具体问题指出发生问题的节点、属性路径、触发问题的值、对应的约束来源以及面向人员的提示信息。数据平台拿到这些结果后，可以直接定位哪一个对象、哪条关系、哪一项规则出了问题，而不必再从程序日志中反查原因。

SHACL 还可以为验证结果设置不同严重级别。例如，同样是数据不符合规则，有些问题必须阻止进入主图，有些问题只需要进入待办，还有些问题暂时只做质量观察。

真正的处理策略仍然属于企业自己的治理流程。企业可以把严重问题配置为拒绝入库，把一般问题交给责任人处理，把低风险问题纳入质量监测。这样，一份 Shape 才有机会连接数据接入、问题发现、任务分派、修复和复检，而不只是停留在一段技术规则里。

验证发生在哪里，同样会影响治理效果。

外部数据刚接入系统时执行验证，可以尽早阻止明显错误进入主图；业务对象发生变更时执行，可以针对受影响的数据做局部检查；定期扫描存量数据，则适合发现组织调整、主数据变动之后遗留下来的历史问题。

本体和 Shapes Graph 也应当纳入版本管理，并在模型或规则发布前进行回归验证。否则，当一条约束发生变化、质量指标突然波动时，团队很难解释究竟是数据质量下降了，还是验证规则已经发生改变。

把业务规则写成 Shape，并不会自动解决规则管理的问题。

一条约束是谁提出的、为什么存在、从什么时候开始生效、适用于哪些数据、验证失败之后由谁处理，这些信息仍然需要明确。如果缺少治理机制，技术团队很容易把某个接口阶段性的临时要求写成全局规则，也可能在业务口径已经变化以后继续保留失效的 Shape。

因此，Shapes Graph 更适合被当作正式的软件和规则资产管理。

每组 Shape 应该拥有稳定标识和版本，修改时保留原因，并配套能够通过和失败的测试数据。规则发布前，既要确认新的异常数据能够被识别，也要检查原本合格的数据是否会受到影响。

如果某项约束准备从提醒升级为强制阻断，也不宜只修改一个严重级别就直接上线。更稳妥的做法是先在存量数据中观察命中范围，确认数据质量现状、修复成本和业务影响，再决定什么时候真正启用阻断。

做到这一步，SHACL 管理的就不只是几条技术规则，而是一套可以追踪、测试和演进的数据治理规则资产。

有了 RDF、OWL 和 SHACL，我们已经可以描述领域中的对象、关系与语义，也能够检查进入知识图谱的数据是否符合预先约定的规则。对于企业知识系统来说，这已经覆盖了“如何描述知识”和“如何控制数据质量”两个重要环节。

如果希望知识模型进一步参与业务运行，还需要处理业务动作及其上下文。

例如，一个权限被授予给谁、在什么条件下发起、作用于哪个对象、最终是否执行成功；一项业务规则被触发以后产生了什么结果；某个 Agent 根据当前知识做出了什么操作，实际结果是否符合预期。这些信息通常来自审计日志、业务事件、工作流记录或者运行过程本身。

它们进入知识体系以后，SHACL 可以继续承担规则验证的工作，发现数据和既定约束之间的偏差。但验证结果并不会自动告诉系统应该怎样修改本体。究竟是源数据出了问题、业务规则已经变化，还是当前的概念和关系设计需要调整，仍然需要结合业务和治理流程判断。

因此，从 SHACL 再往前走，值得关注的是一条更长的链路：业务运行产生事实，数据进入知识体系，规则检查发现偏差，治理人员判断原因，再决定是否调整数据、本体或 Shape。

这也是企业本体真正进入业务之后会持续遇到的问题。建模只是开始，后面还要处理规则如何执行、知识如何更新，以及 Agent 如何在这套知识体系上运行。到了这一阶段，本体才开始从一份领域模型，逐渐变成企业系统能够持续使用和校准的知识基础。