摘要

  • W3C 于 2026 年 9 月 24 日发布的是 SPARQL 1.2 Graph Store Protocol 的修订工作草案；首个公开草案早在 2023 年发布，本次不是正式推荐标准。
  • 对照 2024 年 12 月版本，新稿允许服务器在 GET 未带 Accept 时返回任意 RDF 序列化格式，并明确 ?graph= 的百分号解码结果按 UTF-8 解释。
  • 迁移时应分别验收响应格式、图标识符往返和写入者权限。这是本文的操作建议，不是 W3C 新设的强制记录。

一个定时任务每天读取同一张知识图，过去一直收到 Turtle，于是客户端索性不发送 Accept。只要服务器没有变化，这个省略看起来毫无代价。问题是规范文本不能永远替它兜底：2024 年 12 月的工作草案把无 Accept 的 GET 响应限定为 RDF/XML、Turtle 或 N-Triples；2026 年 9 月的修订改为可以返回任意 RDF 序列化格式，并举出 JSON-LD。这里没有证据表明某台服务器已经改用 JSON-LD，更没有已发生的故障。变化在于客户端过去依赖的格式边界不再相同。

因此，若程序只会解析一种格式，就应明确告诉服务器自己接受什么，再检查响应的 Content-Type 是否与解析能力一致。GET 获取的是图内容的一种表示，不是给图中的断言颁发真实性证明。格式协商成功，也不能被误读成对后续修改的许可。把读懂一份响应和有权修改它混成同一步，往往正是自动化流程最难被看见的假设。

第二个变化落在图名上。图可以直接由请求 IRI 指定，也可以通过图存储服务地址后的 ?graph= 参数间接指定；这种间接方式早已存在。2024 年文本要求对参数值作百分号解码。新文本进一步明确：解码得到的字节按 UTF-8 字符串解释，形成图的 IRI，而且该 IRI 必须是绝对形式，否则返回 400。选一个带非 ASCII 字符的图名做往返测试，便能观察客户端编码与服务端理解是否一致。这只是建议的互操作试验，不能据此宣称存在图名碰撞或安全漏洞。

与这两处字句相邻的是更具破坏力、但并不新鲜的操作：GET 读取，PUT 替换整张图内容，POST 合并内容，DELETE 删除图。2013 年 SPARQL 1.1 图存储协议已经规定了这些 HTTP 管理方式。2026 年草案的安全章节仍把具体授权交给实现，并允许在认证或权限不足时拒绝请求。知道图的 IRI、能成功读取图，都不等于得到 PUT 或 DELETE 的权力；反过来，获准写入的程序也必须辨清自己是替换还是合并。

对运营者而言，迁移验收记录无需宏大，却应精确：客户端发出的 Accept、实际收到的媒体类型、发出的编码图名、解码后的绝对 IRI、每种写入方法对应的账户和授权，以及在测试图上验证的替换或合并效果。本文提出这份记录，是为了把表示形式、目标身份和行动权限三件事交给各自责任人核对；W3C 没有在此次修订中规定这张表。一个 HTTP 200 只说明一次请求成功，不能代替全部治理判断。

W3C 的发布史显示，SPARQL 1.2 图存储协议的首个公开工作草案刊于 2023 年 5 月，2024 年也有多次修订。9 月文本仍可变化，尚非 W3C 推荐标准，更非任何产品的部署报告。可确认的新闻事实很窄：原先可被忽略的两个客户端约定，现在值得被明确测试。是否影响特定系统，要看那个系统自己的实现与运行证据。

来源