本体为什么还要记录“发生过什么”？ Action 如何把业务运行写进知识图谱

一条临时管理员权限已经通过审批。权限系统为张三创建授权，允许他在两小时内修改生产环境中的一个数据集。两小时后，授权按时失效，也没有发生异常访问。

如果只看业务对象的当前状态，这个过程似乎没有什么问题：张三是员工，管理员是一种角色，生产数据集是一类资源，临时授权有明确的失效时间。但一旦需要审计或追溯，问题就会变得具体起来。谁发起了申请，谁批准了它，权限由哪个系统创建，张三是否实际使用过这项权限，修改了什么对象，授权最后又由哪个系统撤销？这些信息如果只存在于日志中，本体看到的仍然只是几个时间点上的状态，很难解释这些状态是怎样形成的。

前两篇讨论本体和 SHACL 时，重点放在业务中的对象、关系和约束。本体可以表达“系统里有什么”，SHACL 可以检查这些数据是否符合规则。Action 补充的是运行过程中的活动事实：某个主体在什么时间，对什么对象执行了什么动作，使用了哪些输入，产生了什么结果，以及这些活动如何改变业务对象的状态。

本体里的 Action 很容易被处理成 Read、Update、Approve、Delete 这一类枚举。例如某个权限策略规定管理员可以执行 Update，于是图中出现“角色—允许操作—Update”的关系。这类关系能够表达动作类型和权限规则，却无法证明某一次修改已经实际发生。

“修改”是一种动作类型，“张三在 10 点 15 分修改了客户表的敏感级别”则是一条具体的动作事实。建模时需要把这两层信息分开：Action Type 定义动作类别，Action Execution 记录某一次实际发生或计划发生的执行。否则后续查询时，“有权修改”“准备修改”和“已经修改”会落在同一种表达里。

Action 也不等同于某个 Java 方法、API 地址或工作流节点。本体负责保存动作的业务含义和相关事实，真正的执行仍然发生在应用、工作流引擎、权限引擎或设备中。图中出现 ex:RevokeAccess，不会让 OWL 自动撤销权限，推理机也不会替业务系统调用接口。

一条能够用于追踪和审计的 Action，通常需要留下几类信息。执行者可能是人员、服务账号、组织或自动化 Agent；动作还需要明确作用对象，以及 origin、target 等与场景有关的位置关系。审批、训练、数据处理等过程还涉及输入和输出，使用了哪份申请、读取了哪个数据集、执行后生成了什么版本，都关系到后续能否还原结果来源。时间也不能总被压缩成一个“发生时间”，持续性任务可能同时存在开始时间、结束时间和持续时长。执行状态与业务结果也应分别记录，一项数据修复任务可以顺利执行完成，但数据质量问题仍然没有被消除。

并不是所有场景都需要完全相同的字段。这组信息更适合作为一套检查思路：一条动作记录进入知识图谱以后，是否已经留下了足够的信息，让后续系统能够把当时发生的事情重新解释出来。

动作建模没有必要重新设计一整套词汇。W3C 已经提供了几套可以组合使用的标准，它们关注的问题并不相同，实际使用时可以根据场景选择。

ActivityStreams 2.0 提供了一套较轻量的 Activity 结构，包括 actor、object、target、origin、result 和 instrument 等关系，适合表达“谁对什么做了什么”，常见于事件流、协作记录和系统通知。Activity 本身仍然是抽象概念，Create、Update、Move 等具体语义通常需要由子类或领域词汇补充。

PROV-O 更关注来源和责任链。prov:Activity 可以关联执行者，声明活动使用了哪些 prov:Entity，又生成了哪些实体；prov:wasAssociatedWith、prov:used 和 prov:wasGeneratedBy 可以把人员、活动、输入和结果连接起来。如果业务需要解释某份数据由谁、经过什么过程产生，PROV-O 比单独设计一组“操作日志属性”更适合承担这部分表达。

OWL-Time 主要处理时间点、时间区间、开始和结束等时间关系。ODRL 中也存在 Action，但它服务的是策略语义：Permission 描述允许在一定条件下对 Asset 执行动作，Prohibition 描述禁止，Duty 表示必须履行的义务。策略中存在某个 Action，只能说明系统定义了这样的规则，某次动作是否实际发生，仍然需要单独保存活动实例。

业务事件较简单时，可以复用 ActivityStreams 的基本结构；需要追踪数据来源和责任关系时，可以引入 PROV-O；遇到复杂时间关系时，再使用 OWL-Time。领域本体主要补充自己的动作类别、状态和结果类型，没有必要把通用能力重新定义一遍。

继续以前面的临时管理员授权为例。ex:GrantTemporaryAccess 表示动作类型，ex:grant-20261010-001 表示已经发生的一次授权活动：

这段数据记录的是权限服务已经完成的一次业务活动，以及这次活动使用的申请、生成的授权、涉及的人员和资源。真正创建权限的仍然是权限系统，本体保存的是能够解释这次授权过程的事实。

如果两个小时后系统撤销了授权，可以再创建一个 ex:RevokeTemporaryAccess 活动，并让它关联 ex:temporary-grant-456。原来的授权记录不宜直接覆盖，否则图中最后只剩下一项“已经失效”的权限，很难继续解释它曾经在什么时间生效、由什么流程创建，又经过什么活动被撤销。

业务系统为了查询方便，可以继续在权限对象上保存 Active、Revoked 这样的当前状态；Action 保存状态变化时对应的活动。查询当前结果时直接读取状态，需要审计和追溯时再沿着动作记录还原变化过程。审批通过后触发授权、授权失败后产生重试，也可以进一步形成活动之间的关系，不过时间上的先后不能直接当作因果证据。只有系统保存了同一流程编号、明确的触发关系或其他可以证明关联的信息，才适合把两个 Action 连成因果链。

本体通常不需要让业务人员重新填写一遍动作过程。权限系统会留下授权记录，审批系统保存流程历史，消息队列传递业务事件，数据库也可能记录重要变更，这些信息都可以成为 Action 的事实来源。

接入前需要先处理数据粒度。一次审批在底层系统里可能对应请求、回调、状态更新等多条日志，对业务来说却只发生了一次审批。如果把每一条技术日志直接转换成 RDF，知识图谱很快会变成另一套日志存储，业务语义反而被大量底层事件淹没。

更合适的方式，是先识别有业务意义的活动，把属于同一次业务动作的多条记录合并成一个 Action，同时保留原始日志、事件或流程编号，方便需要时继续向下追查。以临时授权为例，权限系统完成授权后，可以形成一条较完整的事实：某个权限服务根据一份已审批申请，为张三创建了一项针对生产数据集的临时权限，授权执行成功，并将在两小时后失效。本体由此既能知道“张三当前拥有权限”，也能够追溯这项权限如何产生。

并不是所有动作都有必要长期进入知识图谱。会改变重要业务对象、影响权限或数据质量，以及以后可能涉及责任解释的活动，更适合被保留下来，例如授权、审批、发布、撤销和数据修复。心跳、缓存命中等底层技术事件可以继续存在日志系统中，需要调查时再通过事件 ID 或流程编号与 Action 建立关联。

Action 中通常还会出现人员、资源、时间和访问目的等信息，敏感程度往往高于普通静态关系。哪些角色可以查询动作历史、记录需要保存多久、哪些字段需要脱敏，也需要纳入数据治理范围。

Action 进入知识图谱以后，SHACL 可以对活动记录做进一步检查。例如，一次成功的临时授权应该包含执行系统、授权对象、审批人、开始时间和结束时间，并指向实际生成的权限；如果授权失败，记录中应该存在失败原因，也不应同时声明已经生成了一项有效权限；撤销活动则应该关联一项真实存在的授权。

SHACL 处理的是动作数据是否完整、前后是否一致。能否授权仍由权限系统根据业务规则判断，授权本身也由业务系统执行。SHACL 可以发现缺少审批人、时间关系异常、状态和结果相互矛盾等问题，治理人员再根据验证结果回到对应流程、事件和日志继续调查。

动作数据持续积累以后，还会暴露本体模型与实际业务之间的偏差。如果大量审批都需要人工补充“数据用途”，申请本体中可能缺少相关概念；如果很多授权因为资源范围表达不清而失败，Resource Scope 的粒度可能需要继续调整；如果系统经常出现无法归入现有分类的动作状态，现有状态定义也值得重新检查。

这些现象可以作为本体修改的证据，但单次异常不足以直接触发模型变化。失败可能来自程序故障，也可能只是数据延迟。更稳妥的处理方式，是持续汇总一段时间内的动作记录，观察哪些问题重复出现，再形成模型调整方案，经过评审后发布新的本体版本和 SHACL 规则。

RDF 和 OWL 负责描述业务中的对象、概念和关系，SHACL 检查实例数据是否符合约束。加入 Action 后，知识图谱中多出了一条与业务运行过程有关的时间线，主体、对象、输入、结果和责任关系可以被连接起来，状态变化也有了可以追溯的来源。

应用和业务系统继续负责执行动作，事件系统负责捕获运行事实，知识图谱保存这些活动的业务语义，SHACL 用来发现数据中的缺失与矛盾，治理人员再根据运行证据判断模型是否需要调整。各层系统的职责没有被混在一起，Action 也不会退化成简单的日志搬运。

对于企业本体来说，这一层运行数据还有长期价值。哪些规则在实际流程中频繁遇到问题，哪些概念需要反复人工补充，哪些状态无法覆盖真实运行，都可能在 Action 中留下痕迹。本体由此获得的不只是历史记录，也是一组可以继续检验自身设计是否合理的业务证据。

W3C PROV-O The PROV Ontology

W3C ActivityStreams 2.0 Vocabulary

W3C Time Ontology in OWL