要約

  • 2026年9月24日付の SPARQL 1.2 Graph Store Protocol は改訂されたW3C作業草案であり、最初の公開草案でも最終勧告でもない。
  • 2024年12月版と比べ、Accept のないGETで返せるRDFの形式が広がり、?graph= のパーセント復号後のバイト列をUTF-8で読むことが明記された。
  • 表現形式、グラフの同一性、書き込み権限を別々に試すべきだというのが本稿の提案である。W3Cが新しい認証手続きを定めたわけではない。

決まった書式で届くはずの資料が、別の書式で届いたらどうなるか。データ連携の現場では、その変化は大きな設計変更より小さな省略から始まる。あるクライアントがグラフをGETするとき Accept を付けず、従来の三形式だけを読めるとしよう。2024年12月の草案なら、ヘッダーがない場合の応答はRDF/XML、Turtle、N-Triplesのいずれかに限られていた。9月24日の文面は、JSON-LDを例に挙げつつ、任意のRDFシリアライズ形式を許す。すべてのサーバーが直ちにJSON-LDを返すという話ではない。暗黙の形式保証が変わった、という限定されたニュースである。

読める形式が限定されているなら、クライアントは希望を Accept で伝え、応答の Content-Type を確認する必要がある。RDFの表現形式はデータを運ぶ方法であって、そこで述べられた内容の真偽を認定するものではない。形式を正しく解析できたことを、グラフを書き換える許可と取り違えてもいけない。成功したGETが示すのは、許された読み取りが成功したという範囲にとどまる。

もう一つの変更は、サービスURLの ?graph= にグラフIRIを埋め込む間接指定に関わる。この指定方法自体は以前からある。2024年版はパーセント符号化された値を復号すると書いていた。2026年版は、得られたバイト列をUTF-8で表したIRIの文字列として解釈すると明示した。IRIは絶対形式でなければならず、そうでなければ400となる。非ASCII文字を含むグラフ名で送信から受信までを確かめれば、両端が同じ対象を指しているか検証しやすい。ただし、現実に衝突や攻撃が起きたと示す資料はない。

この改訂を「グラフを操作する新しい権限」と呼ぶのは誤りだ。GETは取得、PUTは内容の置き換え、POSTは追加的なマージ、DELETEは削除に対応する。これらの骨格は2013年のSPARQL 1.1勧告にすでにあった。作業草案は認可の具体策を実装側に委ね、認証不足や権限不足への応答を想定している。正しいIRIを知ることと、そのグラフを消せることの間には決定的な距離がある。同時に、書き込み可能な自動処理はPUTとPOSTの差を見落としてはならない。

移行時の受け入れ記録には、送った Accept、返ったメディアタイプ、符号化した graph 値、復号後の絶対IRI、各メソッドを許された主体、そしてテスト用グラフで確認した効果を残せばよい。これは本稿の運用上の提案で、W3Cが要求する帳票ではない。一つのHTTP応答をもって、形式、対象、権限の三つを同時に承認したことにしないための切り分けである。

W3Cの公開履歴では、SPARQL 1.2の最初の公開作業草案は2023年5月にさかのぼる。今回も変更され得る草案であり、実装の成績表ではない。運用上の影響を語るには個別のサービスを試す証拠が要る。今確かに言えるのは、クライアントの二つの無言の前提が、最新の文書では無視しにくくなったという点までだ。

出典