W3C Profiles 草案的符合性继承仍缺完整证明层

摘要

W3C Dataset Exchange Working Group 于 2026 年 8 月 20 日发布 The Profiles Vocabulary 首次公开工作草案。它已进入 Recommendation track，但不是 W3C 背书的标准，内容仍可修改。
网页草案写入一条属性链：资源若符合某个 profile，而该 profile 是另一项规范的 profile，机器便可推导资源也符合上位规范。草案同时说明，各共同体自行界定“符合”意味着什么、怎样测试。
6 月的一项修订纠正了属性链中两个属性的顺序；另一项公开 Issue 仍把这条公理标为 at risk，而且嵌入草案的 Issue 文字仍显示旧顺序。
与草案同日发布的 RDF Turtle 文件在检索时没有 owl:propertyChainAxiom 声明。实现报告列出若干案例，但逐词汇元素的证据表仍保留 xx 占位符。
Data Shapes 仓库中的公开反例说明：一个 profile 的局部验证可以通过，却未必足以证明上位规范全部满足。任何进入采购、认证或自动化政策的继承关系，都应附带“符合性继承凭证”。

一条三元组背后有三层权限

Profile 并不是某项规范的简单副本。一个行业、地区或应用共同体可能对上位规范收紧可选项，加入扩展，把多项规范组合起来，或者提供使用指引。PROF 的目标，是把这些关系和配套材料变成机器可发现的结构。

在这套结构中，prof:isProfileOf 把 profile 与上位规范或另一层 profile 连接起来。Profile 还可以关联约束文件、验证器、schema、词汇表、指南、映射和示例，并为每类资源标明角色。共同体可以扩充这些角色。这样，客户端不只知道“有一个 profile”，也能找到实现它所需的材料。

最具治理后果的是符合性继承。8 月 20 日版 HTML 草案给出如下属性链：

dct:conformsTo owl:propertyChainAxiom ( dct:conformsTo prof:isProfileOf )

机器从资源出发，先沿 dct:conformsTo 到达 profile，再沿 prof:isProfileOf 到达上位规范，于是补出新的 dct:conformsTo 关系。对于目录、数据交换和自动化代理，这很有吸引力：每个消费者无需重新遍历关系，就能复用一个简洁结论。

但这条新三元组至少包含三种不同权限。第一层是图推导权限：给定输入和公理，推理器是否应该生成它。第二层是测试权限：谁定义了符合性，验证器覆盖了哪些规则。第三层是决策权限：采购方、监管者或认证方是否接受该证据。只有第一层可以由属性链本身解决。

文件状态也必须同行。该稿是 Recommendation track 上的 First Public Working Draft，不是 Recommendation。W3C 对 Working Draft 的解释是：它用于公开评审和历史记录，仍在推进中，并未获得 W3C 背书。工作组同意发布，不等于联盟及其成员已经认可技术结论。

语义推导很精确，符合性定义却不能自动产生

草案在介绍属性链后立即把实质定义权留给各共同体：它们可以界定 profile 以及被 profile 化的对象的符合性含义，也可以决定如何测试。这个限定不是附注，而是整个公理能否进入真实决策的边界。

推理器的精确性很容易制造一种错觉。只要图中两条边和属性链存在，新增三元组的过程可以完全确定。但“资源符合 profile”本身可能来自不同证据：一项完整验证、一组局部约束、发布者自我声明，甚至只是目录中的描述。机器对逻辑路径的确定性，不能弥补起点证据的不确定性。

草案关于 null profile 的说明把问题说得更具体。Null profile 的用途，是为缺少验证机制的规范提供一套可测试表达。可原规范的规则可能只以自然语言或不完整模型表述，因此草案承认不存在普适而精确的构造方法。把规则转成 SHACL shapes，本身就包含解释、覆盖范围和遗漏风险。

PROF 还区分直接层级和更远祖先。prof:isProfileOf 表示直接声明的 profile 关系；prof:isTransitiveProfileOf 用于展示经多层 profile 链到达的上位规范，帮助客户端免去遍历。如果采用后一便利属性，相关祖先关系应完整列出。不过，草案没有规定每一种实现必须怎样执行这些推导。

因此，conformsTo 至少应带上来源标签：它是发布者直接声明、RDF 推理生成、验证器测试通过，还是由某个有权限的机构确认。把这些不同结果压成同一个字段，才是真正的治理风险。

顺序已经修正，是否保留公理仍未解决

公开 Issue 记录显示，这条看似简短的属性链经历过实质修订。Issue 58 指出旧稿把两个属性的顺序写反。2026 年 6 月，仓库提交把介绍、示例、属性定义表和 at-risk 清单统一改为先 dct:conformsTo、后 prof:isProfileOf。该 Issue 于 6 月 26 日关闭。

另一项 Issue 29 并未随之关闭。它仍保持 open 和 at-risk 标签，议题不是属性顺序，而是这条属性链是否应当纳入 PROF。5 月新增的讨论把它与 null profile 的完整性，以及 Data Shapes 仓库中的反例联系起来。

于是，8 月 20 日网页草案出现了一个可观察的版本差：正文、示例、定义表和附录已经使用修正后的顺序，自动嵌入的 Issue 29 文字却仍展示旧顺序。熟悉背景的人可以判断哪一处是当前意图；只抽取某个段落、Issue 摘要或缓存片段的系统未必能做到。

附录对成熟度同样坦率。它把 profile 类、各种属性、资源角色和 conformsTo 公理均列为待实现证据支持的 at-risk 功能。这个标签并不等于“准备删除”，而是说明设计需要可复现的实现记录，才能从工作草案继续向前。

人读的网页和机器载入的文件尚未承载同一规则

W3C 新闻稿把一份带日期的 prof.ttl 指定为 PROF 的 RDF Turtle 编码。对自动化系统而言，这个文件比网页叙述更直接：它可以下载、校验哈希并加载到推理器。

检索 8 月 20 日的 Turtle 文件时，可以看到 prof:isProfileOf 被定义为 OWL object property，也被设为 prof:isTransitiveProfileOf 的 subproperty。使用说明谈到约束继承，传递属性的定义也描述 profile 层级的闭包。但文件中没有 owl:propertyChainAxiom 声明。

这不能证明遗漏是错误。公理仍处于 at-risk 状态，草案也说某些附加公理可以放在独立资源中。问题在于，公开发布表面没有清楚告诉实施者：网页中的这条公理是规范性规则、可选模块、讨论中的候选，还是尚未同步到 Turtle 的内容。

结果会真实改变执行。有的工具开发者可能按 HTML 手动加入公理；有的只加载带日期的 Turtle 文件，因此不产生继承关系；还有的使用未带日期的 namespace 文件。三者都可能声称在处理同一版 PROF，却生成不同图谱。

治理上的最低要求不是预先决定技术答案，而是让 HTML、下载文件、Issue 状态与测试清单表达同一个答案；若暂时不同，就明确说明差异及其适用范围。

实现报告有案例，逐功能证明仍未成形

FPWD 把概念模型、词汇规范和 Test Suite 附录列为合规所需的规范性部分。附录称有一套以 SHACL 验证模板和操作说明组成的软件测试套件。独立的实现报告进一步列出五个案例，并把它们归为三个独立实施者群组。

其中 Cheka 被描述为沿 profile 层级向上寻找验证资源的 Python 工具，正好接近本文讨论的执行机制。报告还列出 LOCI ontology、ODRL profile 指南、OGC 层级和持久 profile 目录。它们说明 PROF 并非没有实践对象。

然而，实现报告最关键的“每个词汇元素的实现声明”表仍然只有 xx：元素、标签、实施者和在线位置都未填。报告展示的测试套件仓库链接在检索时返回 404，虽然仓库的 gh-pages 分支中另有 testsuite 目录。这里不能据此说“没有测试”，只能说公开页面尚未把每项 at-risk 功能、独立实现和可复现结果连成一条完整证据链。

2026 年工作组章程给出了目标。把 PROF 重新发布为 Recommendation-track 文件属于暂定交付项。规范若要越过 Candidate Recommendation，章程预期每项功能至少有两个独立、可互操作实现，并由开放测试验证。章程还要求尽早制定测试计划，与 Data Shapes Working Group 协调；工作组任期到 2028 年 4 月。当前空白是下一步工作清单，而不是过期结论。

一个反例追问“通过”究竟覆盖多少

Data Shapes Issue 882 构造了一个有针对性的例子。某个 shapes graph 只实现上位 OWL 规范的一部分检查；它所包含的检查本身是正确的，数据也通过了这些检查。但上位模型还有一项未被 shapes 覆盖的约束。经过 entailment 后，同一对象落入两个互斥类别，说明数据并不符合完整上位规范。

局部验证器没有对它实际检查的内容撒谎。问题是覆盖不完整。如果属性链把“通过该 profile”直接推为“符合上位规范”，最终三元组就超过了验证器能证明的范围。

这只是一项公开提交的 open issue，不是两个工作组已经形成的共识。它也没有证明所有 profile 继承都不可靠。它提出了最终设计必须回答的可验证问题：profile 需要达到怎样的完整度，才能把一个局部通过结果提升为上位符合性？

可能的答案包括：要求完整验证器、把描述性 profile 关系与已测试符合性分开、缩小公理作用、声明 entailment regime 与覆盖范围，或由各共同体单独加载推导模块。无论选择哪条路径，决策系统都不能靠猜测补全。

让每次继承都带上“符合性继承凭证”

任何会影响采购、监管、认证或自动执行的继承关系，都应附带一份紧凑凭证。它首先要记录 profile 和上位规范的精确版本与哈希、直接 prof:isProfileOf 路径、实际加载的机器可读词汇文件与公理。

其次，凭证要说明谁有权定义符合性、定义用于什么场景；列出带角色的约束、验证器、schema、指南与映射；记录推理器、验证引擎、entailment regime 和配置；写明测试套件版本、逐功能覆盖、反例、已知盲区、独立实现证据、at-risk Issue 与复验触发条件。

最后必须标注结果类型。发布者声明、机器推导的 RDF 三元组、验证器通过、认证结论和法律判断不是同一回事。低风险目录字段也许可以接受第一或第二种；合同保证可能要求完全不同的权限与证据。这个选择应由有权限的决策者作出，而不是由缺失来源信息的三元组代替。

按照 Heng Lu 对互联网治理委托—代理问题的分析，标准机构是受托技术代理，profile 共同体、工具开发者与自动推理器同样如此。受影响的主体若看不到谁定义规则、哪份文件执行规则、谁把结果升级为决策，就无法判断这条委托链是否越权。

证据没有证明什么

这份 FPWD 不是 Recommendation，本文也不预测公理最终保留还是删除。Turtle 文件没有相关声明，不足以推断工作组意图；它只证明检索时的人读与机读发布表面没有承载同一规则。

实现报告确实列出案例，不能因为逐元素表仍为空就说不存在实现。显示链接返回 404，也不等于仓库里没有测试。Issue 882 是值得处理的反例，不是 W3C 已确认的结论。本文没有指控任何实施者夸大符合性。

“符合性继承凭证”是 Daniel Kade 提出的治理控制，不是 W3C 已宣布的规范要求、认证制度或技术解决方案。

W3C Profiles 草案可继承符合性，证明层仍未定案

为何重要

摘要

一条三元组背后有三层权限

语义推导很精确，符合性定义却不能自动产生

顺序已经修正，是否保留公理仍未解决

人读的网页和机器载入的文件尚未承载同一规则

实现报告有案例，逐功能证明仍未成形

一个反例追问“通过”究竟覆盖多少

让每次继承都带上“符合性继承凭证”

证据没有证明什么

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报