CyberLibrarian

【注意】 このドキュメントは、W3CのSPARQL 1.1 Update W3C Recommendation 21 March 2013の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2013年8月3日

W3C

SPARQL 1.1更新

W3C勧告 2013年3月21日

本バージョン:
http://www.w3.org/TR/2013/REC-sparql11-update-20130321/
最新バージョン:
http://www.w3.org/TR/sparql11-update/
旧バージョン:
http://www.w3.org/TR/2012/PR-sparql11-update-20121108/
編集者:
Paul Gearon <pgearon@revelytix.com>
Alexandre Passant, DERI Galway at the National University of Ireland, Galway, Ireland <alexandre.passant@deri.org>
Axel Polleres, Siemens AG <axel.polleres@siemens.com>

このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。

翻訳版も参照してください。

Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

要約

このドキュメントでは、RDFグラフ用の更新言語であるSPARQL 1.1更新を記述しています。これは、RDF用のSPARQLクエリ言語に由来する構文を使用します。更新オペレーションは、グラフ・ストア内のグラフのコレクション上で実行されます。オペレーションは、グラフ・ストア内のRDFグラフを更新、作成、削除するために提供されます。

このドキュメントのステータス

置き換えられる可能性

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、SPARQLワーキンググループが作成した以下の11のSPARQL 1.1勧告のうちの1つです。

  1. SPARQL 1.1概要
  2. SPARQL 1.1クエリ言語
  3. SPARQL 1.1更新（このドキュメント）
  4. SPARQL 1.1サービス記述
  5. SPARQL 1.1統合クエリ
  6. SPARQL 1.1クエリ結果JSONフォーマット
  7. SPARQL 1.1クエリ結果CSVおよびTSVフォーマット
  8. SPARQLクエリ結果XMLフォーマット（第2版）
  9. SPARQL 1.1含意レジーム
  10. SPARQL 1.1プロトコル
  11. SPARQL 1.1グラフ・ストアHTTPプロトコル

本質的な変更なし

旧バージョン以降、このドキュメントには実質的な変更はありませんでした。マイナーな編集上の変更がある場合には、変更履歴に詳細が記述されており、色分けした差分として見ることができます。

コメントの送信

public-rdf-dawg-comments@w3.org（公開アーカイブ）にコメントをお送りください。このドキュメントに対するSPARQLワーキンググループの作業は完了していますが、コメントは正誤表や今後の改定で扱われることがあります。公開討論は、public-sparql-dev@w3.org（公開アーカイブ）で歓迎します。

W3Cによる承認

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

特許

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権（Essential Claim(s)）を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

目次

1 はじめに
    1.1 文書規定
        1.1.1 言語形式
        1.1.2 用語
2 グラフ・ストア
    2.1 グラフ・ストアとSPARQLクエリ・サービス
    2.2 SPARQL 1.1更新サービス
    2.3 含意と整合性
3 SPARQL 1.1更新言語
    3.1 グラフ更新
        3.1.1 INSERT DATA
        3.1.2 DELETE DATA
        3.1.3 DELETE/INSERT
            3.1.3.1 DELETE（参考情報）
            3.1.3.2 INSERT（参考情報）
            3.1.3.3 DELETE WHERE
        3.1.4 LOAD
        3.1.5 CLEAR
    3.2 グラフ管理
        3.2.1 CREATE
        3.2.2 DROP
        3.2.3 COPY
        3.2.4 MOVE
        3.2.5 ADD
4 SPARQL更新形式モデル
    4.1 一般的な定義
        4.1.1 グラフ・ストア
        4.1.2 抽象的な更新オペレーション
    4.2 補助的な定義
        4.2.1 データセット-和集合
        4.2.2 データセット-DIFF
        4.2.3 Dataset( QuadPattern, μ, DS, GS )
        4.2.4 Dataset( QuadPattern, P, DS, GS )
    4.3 グラフ更新オペレーション
        4.3.1 データ挿入オペレーション
        4.3.2 データ削除オペレーション
        4.3.3 削除・挿入オペレーション
        4.3.4 ロード・オペレーション
        4.3.5 クリア・オペレーション
    4.4 グラフ管理オペレーション
        4.4.1 作成オペレーション
        4.4.2 削除オペレーション
    4.5 形式モデルへの更新リクエストのマッピング
5 適合性

付録

A セキュリティに関する留意点（参考情報）
B インターネット・メディア・タイプ、ファイル拡張子、およびマッキントッシュ・ファイル・タイプ
C SPARQL 1.1更新文法
D 参考文献
    D.1 規範的な参考文献
    D.2 その他の参考文献

1 はじめに

SPARQL 1.1更新は、グラフ・ストア内のRDFグラフに対する更新を指定し実行するための標準的な言語となることを目指しています。

SPARQL 1.1更新は次の機能を提供します。

このドキュメントは、特に次の他の仕様書と関係があります。

SPARQL 1.1更新は対で用いる言語の片方で、SPARQL 1.1クエリ言語とともに用いることを想定しています。現在のドキュメントは、SPARQL 1.1クエリ言語仕様の文法と一部の定義を参照しています。

SPARQL 1.1グラフ・ストアHTTPプロトコル仕様は、PUTやDELETEなど、標準的なHTTPメソッドを用いて更新オペレーションを実行するためにHTTPプロトコルを採用しています。シンプルかつよく知られているAPIを提供するものの、HTTPプロトコルのメソッドには限界があるため、必然的にそのオペレーションには制約があります。対照的に、SPARQL 1.1更新では、1つのオペレーションで複数の修正が可能で、複合SPARQLクエリを用いて挿入するデータを構築したり、削除するデータを選択したりできます。また、更新言語を用いると、独自のAPIでのオペレーションやHTTPによらない接続が容易になります。

SPARQL 1.1 RDF用プロトコルの仕様は、クライアントによるSPARQL 1.1クエリとSPARQL 1.1更新のオペレーションをSPARQLクエリ処理サービスに伝え、適切な結果を返すための手段を記述しています。SPARQL 1.1クエリとSPARQL 1.1更新（このドキュメント）の仕様を合わせると、より複雑な機能ではあるけれども包括的なSPARQL 1.1グラフ・ストアHTTPプロトコルの代替手段となります。

1.1 文書規定

1.1.1 言語形式

このドキュメントのオペレーションには、オペレーションの使用方法を示す言語形式が含まれています。これは、SPARQL 1.1クエリのドキュメントで述べられている形式文法の実例となる形式を意図しています。このドキュメントの言語形式とSPARQL 1.1クエリの文法に相違がある場合には、SPARQL 1.1クエリの形式文法に従います。

例えば、このドキュメントでは、言語形式は、非形式的に次のように表します。

( WITH IRIref  )?
( ( DeleteClause InsertClause? ) | InsertClause )
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

角括弧が選択性を表すEBNFの他の形式とは異なり、このドキュメントでは、[]は、SPARQLクエリと同様に、空白ノードに用います。|は選択肢を表すために用い、()は用語のグループ化に用い、?は0または1つの用語のオカレンスを、*は0以上のオカレンスを、+は1つ以上のオカレンスを表します。

ボールド体は、言語キーワードを示します。イタリック体は、SPARQL 1.1クエリ文法で定義されている構文事項を示し、リンクによって生成規則を参照することがあります。イタリック体ではないテキストは、形式文法ではより複雑な（かつ正確な）定義を持っているローカルな用語を示します。

更新リクエストの例は次のように表します。

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT { <http://example/egbook> dc:title  "This is an example title" } WHERE {}

注意:

更新リクエストのPREFIXの定義とIRIの構文は、一般的にSPARQL1.1クエリ言語と同じ規定に従います。

Turtle構文では、データを次のように表します。

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/books/> .
:book0  dc:title  "SPARQL Tutorial" .

1.1.2 用語

ドキュメントが、しなければならない（MUST）、してはならない（MUST NOT）、すべきである／する必要がある（SHOULD）、すべきでない／する必要がない（SHOULD NOT）、することができる／してもよい（MAY）、推奨される（recommended）という単語を使用し、強調されたテキストとして出現するとき、RFC 2119 [RFC2119]で記述されているとおりに解釈されなければなりません。

このドキュメントの全体で、次の用語も使用しています。

このドキュメントでは、次の用語も、SPARQL 1.1クエリ言語の定義に従って使用します。

  • QuadPattern - トリプルの集合のパターンを指す構文構成子で、ConstructTriplesに似ていますが、トリプルの集合が名前付きグラフに挿入または削除されることを示すために潜在的にGRAPHキーワードを伴います。
  • QuadData - 変数のないQuadPattern。
  • GroupGraphPattern - トリプルの集合を参照するための構文構成子で、複雑な制約を伴う可能性があります。

2 グラフ・ストア

グラフ・ストアは、1つのサービスが管理するRDFグラフの可変コンテナです。SPARQL 1.1クエリ言語によってオペレーションを行うRDFデータセットと同様に、グラフ・ストアには、デフォルト・グラフを格納する1つの（名前のない）スロットと、名前付きグラフを格納する0以上の名前付きスロットが含まれています。オペレーションは、修正するグラフを指定するか、そのオペレーションのデフォルト・グラフに頼ることができます（MAY）。上書きされなければ（例えば、SPARQLプロトコルによって）、ストアの名前のないグラフが、そのストアに対するオペレーションのデフォルト・グラフになるでしょう。実装によっては、名前のないグラフは、別のグラフ、名前付きグラフを記述しているグラフ、他のグラフの和集合の表現などを参照することもできます（MAY）。

RDFデータセットとは異なり、名前付きグラフを、グラフ・ストアに追加または削除できます。グラフ・ストアは、それが含んでいるグラフに対して正式なものである必要はありません。これは、グラフ・ストアが、ウェブの他の場所で定義されたRDFグラフのローカル・コピーを保持し、元のグラフとは関係なく、そのコピーを修正できることを意味します。

1つの名前のないグラフが存在し、名前付きグラフがないというシンプルなケースでは、SPARQL 1.1更新は、グラフの更新言語として（グラフ・ストアの更新言語ではなく）使用できます。

グラフ・ストアへのアクセス方法に関する情報は、プロトコル仕様とグラフ・ストア・プロトコル仕様で定義されています。グラフ・ストアは、更新サービス（cf.プロトコル）かグラフ・ストア・プロトコル（cf.グラフ・ストア・プロトコル）のいずれかでアクセスできます。いずれの場合でも、グラフ・ストアは、サービスの陰に隠れており、SPARQL更新サービスのURI、または、グラフ・ストア・プロトコルに応答するURIによってアクセス可能となります。

グラフ・ストアの形式的な定義と、SPARQL 1.1更新がそれにどのような影響を与えるかは、SPARQL 1.1更新形式モデルの項で記述しています。

2.1 グラフ・ストアとSPARQLクエリ・サービス

更新リクエストを受け付けて処理するサービス（SPARQLエンドポイントという非公式な用語で呼ばれることが多い）は、更新サービスと呼ばれます。更新サービスが管理しているグラフ・ストアが、クエリ・サービスが提供するRDFデータセットと完全に一致すると仮定することはできません。クエリ・サービスは、更新サービスのグラフ・ストアの一部であるグラフから生成されたRDFデータセットを提供することもできます（MAY）。クエリ・サービスのRDFデータセット内のグラフが、更新サービスのグラフ・ストア内のグラフのサブセットである場合もあります（MAY）。さらに、クエリ・サービスのRDFデータセットと、更新サービスのグラフ・ストアが、同じグラフに対して異なる名前を用いることもあります（MAY）。

2.2 SPARQL 1.1更新サービス

SPARQL 1.1更新リクエストは、一連のオペレーションです。

各リクエストは、SPARQL 1.1更新サービスにより、アトミックに（atomically）処理されるべきです（SHOULD）。「アトミックに」という用語は、リクエスト内に存在するオペレーションの数にかかわらず、1つのリクエストの結果は、影響がないか、完全な影響があるかのいずれかになることを意味します。その結果として生じる同時並行性の問題は、個々の実装が、そのアーキテクチャーに応じて検討すべき事項となるでしょう。特に、更新リクエストにおいて、オペレーションのWHERE句でSERVICEキーワードを使用すると、通常はアトミック性が失われるでしょう。

2つの異なる更新サービスで、その個々のグラフ・ストアに同じ名前を持つグラフが含まれている場合、ストアは独立したエンティティーであるため、片方のサービスで実行した更新がもう一方に伝わると仮定することはできません。これらのサービスの相互の挙動（更新後の自動的な同期など）は、実装に依存します。

2.3 含意と整合性

ストアが、含意された応答を演算できる場合は、SPARQL 1.1含意レジームを参照してください。そうすれば、更新オペレーションは含意されたデータと相互作用を行えます。具体的には、DELETEオペレーションは、実際には影響のない含意されたステートメントの削除を試みることができます。

更新リクエストの完了後に、ストアが自身のグラフの特定の含意レジームに関する整合性をチェックする場合、グラフ・ストアの新たな状況の整合性をチェックできます（MAY）。矛盾が検知された場合、そのストアは、リクエストに対してエラーを返すことができます（MAY）。

同様に注意すべき点は、一部のストアは、RDFSやOWLのような、より高レベルの処理が可能なオントロジーに関して含意を実行できるかもしれないということです。更新は、これらの体系において、これらの含意レジームと相互作用を行えます。

3 SPARQL 1.1更新言語

SPARQL 1.1更新は、グラフ・ストアに対し、2つのカテゴリーの更新オペレーションをサポートしています。

リクエストは一連のオペレーションであり、EOF（End of File）で終了します。複数のオペレーションは、「;」（セミコロン）で区切られます。リクエスト内の最後のオペレーションの後のセミコロンは任意です。実装は、1つのリクエストの複数のオペレーションは、リクエストに出現する順序で連続して実行されるのと同じ結果を保証する形で実行されることを保証しなければなりません（MUST）。

オペレーションの結果はすべて、成功か失敗のいずれかになります。失敗の結果に追加情報を付し、そのリクエストのオペレーションの一部が成功であったことを示すことができます（MAY）。結果の正確な形式は、HTTPやプログラマチックAPIによるSPARQL 1.1プロトコルなどの、使用するインターフェースに依存するため、このドキュメントでは規定していません。1つのリクエストに複数のオペレーションが存在している場合、任意のオペレーションの結果が失敗すれば、一連のオペレーションは中止されなければならず（MUST）、それによって、その後のオペレーションは無視されます。

その後のオペレーションの形式意味論は、このドキュメントの4項で定義しています。

3.1 グラフ更新

グラフ更新オペレーションは、グラフ・ストア内の既存のグラフの変更を行いますが、それを明示的に削除、作成することはありません。しかし、存在しないグラフに空でない挿入を行うと、グラフが暗黙的に作成されるでしょう。つまり、更新リクエストを実行する実装で、トリプルが挿入される前には存在しなかったグラフを黙って自動的に作成すべき（SHOULD）で、何らかの理由でそうならない場合、失敗を返さなければなりません（MUST）。（例えば、実装の資源が十分でないかもしれません。または、実装は、一定のグラフに更新サービスを提供するのみで、暗黙的に作成されたグラフはこの一定の範囲内にないかもしれません。）実装は、トリプルの削除後に空のままのグラフを削除できます（MAY）。

更新オペレーションによってグラフが暗黙的に作成された場合、グラフ・ストアの挙動は、グラフがCREATEオペレーションによって明示的に作成された場合の挙動と関数的に同等でなければなりません（MUST）

SPARQL 1.1更新は、下記のグラフ更新オペレーションを提供します。

  • INSERT DATAオペレーションは、トリプル（リクエスト内でインラインで与えられる）をグラフに追加します。宛先グラフ（destination graph）が存在していなければ、これによって作成されるべきです（SHOULD）。グラフが存在せず、何らかの理由でそれを作成できない場合、失敗を返さなければなりません（MUST）。
  • DELETE DATAオペレーションは、個々のグラフにトリプルが含まれていれば、トリプル（リクエスト内でインラインで与えられる）を削除します。
  • グラフ更新のための基本的なパターンに基づくアクションは、INSERTとDELETE（1つのDELETE/INSERTオペレーションに同時に出現可能）です。これらのアクションは、削除するトリプルのグループと、追加するトリプルのグループで構成されます。トリプルの仕様は、クエリ・パターンに基づいています。INSERT / DELETEとINSERT DATA / DELETE DATAとの違いは、INSERT DATAとDELETE DATAはパターンのテンプレートにバインディングを代入しないという点です。DATA形式には、具象データ（DELETE DATAとINSERT DATAのオペレーション内の変数を含んだトリプル・テンプレートは認められておらず、DELETE DATA内では空白ノードは認められていません。文法の注意8と9を参照）が必要です。具象データに対して特定のオペレーションを持っているということは、大きい、純粋なデータの更新が可能となるリクエストを流すことができることを意味します。
  • LOADオペレーションは、グラフを表しているドキュメントの内容を、グラフ・ストア内のグラフに読み込みます。
  • CLEARオペレーションは、（1つ以上の）グラフのトリプルをすべて削除します。

3.1.1 INSERT DATA

INSERT DATAオペレーションは、トリプル（リクエスト内でインラインで与えられる）をグラフ・ストアに追加します。

INSERT DATA  QuadData

この場合、QuadDataは、オプションでGRAPHブロックにラップされるTriplesTemplate（つまり、トリプル・パターンの集合）によって形成されます。

 ( GRAPH  VarOrIri )? { TriplesTemplate? }

QuadDataの変数は、INSERT DATAリクエストでは認められていません（文法の注意8を参照）。つまり、INSERT DATAステートメントでは、基底トリプル（ground triples）の挿入のみが認められています。QuadDataの空白ノードは、グラフ・ストアの空白ノードとは素であると想定される、つまり、新しい空白ノードとともに挿入されるでしょう。

グラフがQuadDataに記述されていない場合、デフォルト・グラフが仮定されます。グラフ・ストアに存在しないグラフにデータが挿入されれば、それは作成されるべきです（SHOULD）（一定のグラフに対して更新サービスを提供している実装がありえます。その場合、認められていないグラフにデータを挿入した更新リクエストには失敗を返さなければなりません（MUST））。

トリプルは、そのトリプルが既にグラフに存在していれば、アクションなしに「処理された」と考えられる（MAY）ことに注意してください。さらに、

INSERT DATA { GRAPH <g> {} } ...

が<g>を作成しないことに注意してください。ユーザがグラフを作成するだけのつもりであれば、挿入オペレーションより先にグラフ管理のオペレーション（CREATE/LOAD）を使用できます。

例1: トリプルをグラフに追加する

この断片は、グラフ・ストアのデフォルト・グラフに挿入される2つのRDFを記述しています。

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{ 
  <http://example/book1> dc:title "A new book" ;
                         dc:creator "A.N.Other" .
}

事前のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book1> ns:price 42 .

事後のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book1> ns:price 42 .
<http://example/book1> dc:title "A new book" .
<http://example/book1> dc:creator "A.N.Other" .

例2:

このSPARQL 1.1更新リクエストは、本の値段を提供するためにトリプルを追加しています。以前の例（デフォルト・グラフに影響を与えた）とは対照的に、リクエストされた変更は、http://example/bookStoreというIRIで識別される名前付きグラフで発生します。

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ns: <http://example.org/ns#>
INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book1>  ns:price  42 } }

事前のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example/book1> dc:title "Fundamentals of Compiler Design" .

事後のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .
<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> ns:price 42 .

3.1.2 DELETE DATA

DELETE DATAオペレーションは、グラフ・ストアの個々のグラフにトリプルが含まれていれば、トリプル（リクエスト内でインラインで与えられる）を削除します。

DELETE DATA  QuadData

QuadDataは、削除するトリプルを示し、INSERT DATAで記述されているとおりですが、DELETE DATAオペレーションでは、変数も空白ノードも認められていないという点に違いがあります（文法の注意8と9を参照）。

INSERT DATAと同様に、DELETE DATAは、基底トリプルのデータを削除するためのものであり、これが、変数や空白ノードが含まれているQuadDataがDELETE DATAオペレーションでは認められていない理由です。DELETE/INSERTオペレーションは、空白ノードが含まれているトリプルを削除するために使用できます。

存在しないトリプルの削除は影響を与えないことに注意してください。つまり、グラフ・ストアに存在していなかったQuadDataのトリプルは無視されます。空白ノードは、既存のデータとマッチしないため、QuadDataでは認められていません。

例3: グラフからトリプルを削除する

このリクエストは、グラフ・ストアのデフォルト・グラフから削除する2つのトリプルを記述しています。

PREFIX dc: <http://purl.org/dc/elements/1.1/>

DELETE DATA
{
  <http://example/book2> dc:title "David Copperfield" ;
                         dc:creator "Edmund Wells" .
}

事前のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .

事後のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix ns: <http://example.org/ns#> .

<http://example/book2> ns:price 42 .

例4:

このSPARQL 1.1更新リクエストは、削除するトリプルと追加する（ここでは、書名を修正するために使用されている）トリプルの2つのオペレーションで構成されます。以前の例（デフォルト・グラフに影響を与えた）とは対照的に、リクエストされた変更は、http://example/bookStoreというIRIで識別される名前付きグラフで発生します。

PREFIX dc: <http://purl.org/dc/elements/1.1/>
DELETE DATA
{ GRAPH <http://example/bookStore> { <http://example/book1>  dc:title  "Fundamentals of Compiler Desing" } } ;

PREFIX dc: <http://purl.org/dc/elements/1.1/>
INSERT DATA
{ GRAPH <http://example/bookStore> { <http://example/book1>  dc:title  "Fundamentals of Compiler Design" } }

事前のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example/book1> dc:title "Fundamentals of Compiler Desing" .

事後のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://example/book1> dc:title "Fundamentals of Compiler Design" .

3.1.3 DELETE/INSERT

DELETE/INSERTオペレーションは、WHERE句で指定されたクエリ・パターンのバインディングに基づき、グラフ・ストアからトリプルを削除または追加するために使用できます。

( WITH IRIref )?
( ( DeleteClause InsertClause? ) | InsertClause )
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

DeleteClauseとInsertClauseの形式は次のように分解できます。

DeleteClause ::= DELETE  QuadPattern 
InsertClause ::= INSERT  QuadPattern

このオペレーションは、WHERE句でデータを識別し、それは変数の集合に対するバインディングのソリューション・シーケンスを演算するために用いられます。その後、各ソリューションのバインディングは、トリプルを削除するためにDELETEテンプレートに代入され、次に、新しいトリプルを作成するためにINSERTテンプレートに代入されます。ソリューションによって、主語や述語の位置のリテラルのような、バインディングされていない変数や不正なRDF構成子を含んだトリプルが生成されれば、オペレーションの処理時には、そのトリプルは含まれないでしょう。INSERTは、出力グラフで新しいデータをインスタンス化せず、DELETEは何も削除しないでしょう。ソリューション・シーケンスの演算に使用されるグラフは、DELETEとINSERTのテンプレートで修正されたグラフとは異なるかもしれません。

WITH句は、後続する要素（DELETE句、INSERT句、またはWHERE句内）でグラフが明示的に指定されていなければ、その要素を修正またはマッチングを行うグラフを定義します。提供されていない場合は、グラフ・ストアのデフォルト・グラフ（または、WHERE句内で明示的に宣言されているデータセット）が仮定されます。つまり、WITH句は、後続するDELETE句とINSERT句内のQuadPatternと、後続するWHERE句内のGroupGraphPatternの両方を、GRAPHパターンにラップするための糖衣構文と見なせます。これは、1つのオペレーションで、同じグラフを複数回参照しないようにするために使用できます。

オプションのWITH句の後にINSERT句および/またはDELETE句が続きます。挿入の前にトリプルの削除が発生します。オペレーションの削除部分が実行される前に、WHERE句内のパターンが一度だけ評価されます。全体的な処理モデルは、パターンが実行され、DELETEテンプレートをインスタンス化するためにその結果が用いられ、削除が行われ、再びINSERTテンプレートをインスタンス化するためにその結果が用いられ、挿入が実行されるというものです。

DELETE句が省略されれば、オペレーションはデータを挿入するだけです（INSERTを参照）。INSERT句が省略された場合には、オペレーションはデータを削除するだけです（DELETEを参照）。文法上、同じオペレーションでDELETEとINSERTの両方を省略することは認められていません。

USING句とUSING NAMED句は、WHERE句を評価している間に用いられるRDFデータセットに影響を与えます。これは、FROM句とFROM NAMED句がSPARQL 1.1クエリ言語でRDFデータセットを記述するのと同じ方法でデータセットを記述します。更新リクエストにおいてFROMではなくUSINGというキーワードを用いるのは、「DELETE FROM」という記述により発生しえる曖昧さを回避するためです。つまり、WHERE句内のGroupGraphPatternは、明示的なUSING句かUSING NAMED句が指定されている場合には、それらによって記述されたデータセットとマッチし、そうでない場合には、グラフ・ストアとマッチするでしょう。

WITH句は、オペレーションが主に1つのグラフを参照する場合に便利です。WITH句内でグラフ名が指定されていれば、WHERE句を評価する目的のために、これは、指定された名前を持つデフォルト・グラフが含まれるRDFデータセットを定義するでしょう。ただし、USING句またはUSING NAMED句がない場合のみです。USING句および/またはUSING NAMED句内で参照されている1つ以上のグラフが存在していれば、WITH句はWHERE句を評価している間、無視されるでしょう。

WHERE句内のGroupGraphPatternは、SPARQLクエリの「SELECT * WHERE GroupGraphPattern」と同じように評価され、グラフ・ストアから削除または挿入するトリプルを定義するために、すべてのソリューション・バインディングは、先行するDELETEとINSERTのテンプレートに適用されます。

再び、QuadPatternは、TriplesTemplate（つまり、トリプル・パターンの集合）によって形成され、オプションでGRAPHブロックにラップされ、その場合、GRAPH句は、更新されるグラフ・ストア内の指定されたグラフを示します。GRAPH句のないTripleTemplateでは、INSERT句またはDELETE句は、WITH句で指定されているグラフに当てはまり、WITH句が存在しない場合には、グラフ・ストアのデフォルト・グラフに当てはまります。

WITH句の用法を例示すると、次の一般的な形式のオペレーション

WITH <g1> DELETE { a b c } INSERT { x y z } WHERE { ... }

は、次と同等と見なされます。

DELETE { GRAPH <g1> { a b c } } INSERT { GRAPH <g1> { x y z } } USING <g1> WHERE { ... }

明示的なGRAPH句によってWITH句が上書されることに注意してください。WITHは、GRAPHが明示的に規定していない場合に使用するグラフ（デフォルト・グラフとは異なる）を指定するためのフォールバックを提供します。

存在しないトリプルや存在しないグラフのトリプルを削除しても影響はなく、その結果は成功になるでしょう。新しい空白ノードはグラフ・ストア内のどれともマッチできないので、DELETEテンプレートで新しい空白ノードを使用しても何も削除されないため、DELETEテンプレートでは空白ノードは禁止されています。この制限はDeleteClause自身に関してはEBNFにはないものの、文法の注9において明示されているということに注意すべきです。

オペレーションによって、存在しないグラフに挿入を試みた場合には、そのグラフは作成されるべきです（SHOULD）。再び、一定のグラフに更新サービスを提供する実装があり、その場合、認められていないグラフを作成する更新リクエストに失敗を返さなければなりません（MUST）。挿入するデータが何もなければ、グラフは作成されないでしょう。特に、

INSERT ... { GRAPH <g> {} } ...

が<g>を作成しないことに注意してください。ユーザが、挿入するデータに関係なくグラフを作成するつもりであれば、挿入オペレーションより先にグラフの管理オペレーション（CREATE/LOAD）を使用できます。

INSERT句に出現する空白ノードは、CONSTRUCTクエリのテンプレート内の空白ノードと同様のオペレーションを行います。つまり、それはWHERE句の任意のソリューションに再インスタンス化されます。詳細に関しては、下記のSPARQLクエリ1.1内の空白ノードを持つテンプレートとDELETE/INSERTの形式意味論を参照してください。WHERE句内の空白ノードは、SPARQLクエリと同じ方法でデータとマッチします。

例5:

「Bill」という名を持つすべての人を「William」という名に変更するためにグラフhttp://example/addressesを更新する例。

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

WITH <http://example/addresses>
DELETE { ?person foaf:givenName 'Bill' }
INSERT { ?person foaf:givenName 'William' }
WHERE
  { ?person foaf:givenName 'Bill'
  }

事前のデータ:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/president25> foaf:givenName "Bill" .
<http://example/president25> foaf:familyName "McKinley" .
<http://example/president27> foaf:givenName "Bill" .
<http://example/president27> foaf:familyName "Taft" .
<http://example/president42> foaf:givenName "Bill" .
<http://example/president42> foaf:familyName "Clinton" .

事後のデータ:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/president25> foaf:givenName "William" .
<http://example/president25> foaf:familyName "McKinley" .
<http://example/president27> foaf:givenName "William" .
<http://example/president27> foaf:familyName "Taft" .
<http://example/president42> foaf:givenName "William" .
<http://example/president42> foaf:familyName "Clinton" .
3.1.3.1 DELETE（参考情報）
( WITH  IRIref )?
DELETE  QuadPattern 
( USING ( NAMED )? IRIref )*
WHERE GroupGraphPattern

DELETEオペレーションは、DELETE/INSERTオペレーションのINSERT部分がない形式です。DELETE/INSERTに準拠している実装は、このオペレーションも正しく実行できるでしょう。DELETEオペレーションは、明確にするために、ここでは別途に記述しています。DELETE/INSERTと同じように、存在しないトリプルや存在しないグラフのトリプルを削除しても影響はなく、その結果は成功になるでしょう。

DELETEテンプレートでGRAPHが指定されれば、これは影響を受けたグラフになるでしょう。そうでない場合、オペレーションは、WITH句内でグラフが指定されていればそのグラフに適用され、そうでない場合には、デフォルト・グラフに適用されるでしょう。

WHERE句は、既存のグラフのデータを識別し、テンプレートで使用するバインディングを作成します。GroupGraphPatternを適用するグラフは、DELETE/INSERTと同じ規則に従います。

例6:

この例のリクエストは、ストアのデフォルト・グラフからすべての古い本（1970年より前の日付のもの）のデータを削除します。

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

DELETE
 { ?book ?p ?v }
WHERE
 { ?book dc:date ?date .
   FILTER ( ?date > "1970-01-01T00:00:00-02:00"^^xsd:dateTime )
   ?book ?p ?v
 }

WHERE内のパターンは、グラフ・ストアに対してマッチングが行われます。WHERE句に対するソリューションの結果として生じるシーケンスは、SPARQL 1.1クエリのCONSTRUCTと同じように、DELETEテンプレートのトリプル・パターンをインスタンス化するために用いられます。その後、結果として生じるトリプルが、グラフ・ストアから削除されます。

事前のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book1> dc:title "Principles of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .

事後のデータ:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .

例7:

この例のリクエストは、グラフhttp://example/addressesから「Fred」という名を持つものに関するステートメントをすべて削除します。WITH句が存在しており、これは、グラフhttp://example/addressesは、トリプルが削除されたものであるということと、WHERE句がマッチするものであるということの両方を意味します。

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

WITH <http://example/addresses>
DELETE { ?person ?property ?value } 
WHERE { ?person ?property ?value ; foaf:givenName 'Fred' }

事前のデータ:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox <mailto:bill@example> .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .
<http://example/fred> foaf:mbox  <mailto:fred@example> .

事後のデータ:

# Graph: http://example/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

INSERTとDELETEを組み合わせた複数のオペレーションについて説明しているDELETEの別の例を、次の項の最終の例で提供しています。

3.1.3.2 INSERT（参考情報）
( WITH  IRIref )?
INSERT  QuadPattern 
( USING ( NAMED )?  IRIref )*
WHERE GroupGraphPattern

INSERTオペレーションは、DELETE/INSERTオペレーションのDELETE部分がない形式です。DELETE/INSERTに準拠している実装は、このオペレーションも正しく実行できるでしょう。INSERTオペレーションは、明確にするために、ここでは別途に記述しています。

INSERTテンプレートでGRAPHブロックが指定されれば、これは影響を受けたグラフになるでしょう。そうでない場合、オペレーションは、デフォルト・グラフに適用されるか、WITH句内でグラフが指定されていればそのグラフにそれぞれ適用されるでしょう。USING (NAMED)句が存在していなければ、WHERE句内のパターンは、グラフ・ストアとマッチし、そうでない場合には、USING (NAMED)句によって指定されているデータセットにマッチするでしょう。WHERE句に対するマッチは、挿入されるトリプルを決定するためにテンプレートに適用されるバインディングを作成します（DELETE/INSERTと同じ規則に従って）。

ソリューション・シーケンスから発生するインスタンス化によって、主語や述語の位置のリテラルのような、バインディングされていない変数や不正なRDF構成子を含んだトリプルが生成されれば、トリプルは挿入されません。テンプレートには、変数のないトリプル（基底的または明示的なトリプルとして知られている）を含むことができ、ソリューション・シーケンスが空でなければ、これも挿入されるでしょう。

例8:

この例は、パターンに基づいて、ある名前付きグラフから別の名前付きグラフにトリプルをコピーします。

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT 
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
       { ?book dc:date ?date .
         FILTER ( ?date > "1970-01-01T00:00:00-02:00"^^xsd:dateTime )
         ?book ?p ?v
  } }

事前のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .
# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book4> dc:title "SPARQL 1.0 Tutorial" .

事後のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book2> ns:price 42 .
<http://example/book2> dc:title "David Copperfield" .
<http://example/book2> dc:creator "Edmund Wells" .
<http://example/book2> dc:date "1948-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .
# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1977-01-01T00:00:00-02:00"^^xsd:dateTime .

<http://example/book4> dc:title "SPARQL 1.0 Tutorial" .

例9:

この例は、名前と電子メールのトリプルを、ある名前付きグラフから別のグラフにコピーします。一部の個人は、アドレスを持っていないかもしれませんが、それに関係なく、名前はコピーされます。

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

INSERT 
  { GRAPH <http://example/addresses>
    {
      ?person  foaf:name  ?name .
      ?person  foaf:mbox  ?email
    } }
WHERE
  { GRAPH  <http://example/people>
    {
      ?person  foaf:name  ?name .
      OPTIONAL { ?person  foaf:mbox  ?email }
    } }

事前のデータ:

# Graph: http://example/people
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf:  >http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

_:a  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .
# Graph: http://example/addresses
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

事後のデータ:

# Graph: http://example/people
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf:  >http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

_:a  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .
# Graph: http://example/addresses
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .

_:b  foaf:name       "Bob" .

例10:

この例のリクエストは、パターンに基づいて、ある名前付きグラフから別の名前付きグラフに、最初にトリプルをコピーし、次にPhysical Objectsと分類されているすべてのコピーされた物体に関するトリプルを削除します。これは、1つのリクエスト内の2つのオペレーションについて説明しています。それらは両方とも、同じPREFIXの定義を共有しています。

PREFIX dc:  <http://purl.org/dc/elements/1.1/>
PREFIX dcmitype: <http://purl.org/dc/dcmitype/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT
  { GRAPH <http://example/bookStore2> { ?book ?p ?v } }
WHERE
  { GRAPH  <http://example/bookStore>
     { ?book dc:date ?date . 
       FILTER ( ?date < "2000-01-01T00:00:00-02:00"^^xsd:dateTime )
       ?book ?p ?v
     }
  } ;

WITH <http://example/bookStore>
DELETE
 { ?book ?p ?v }
WHERE
 { ?book dc:date ?date ;
         dc:type dcmitype:PhysicalObject .
   FILTER ( ?date < "2000-01-01T00:00:00-02:00"^^xsd:dateTime ) 
   ?book ?p ?v
 }

事前のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1996-01-01T00:00:00-02:00"^^xsd:dateTime .
<http://example/book1> a dcmitype:PhysicalObject .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .
# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example/book4> dc:title "SPARQL 1.0 Tutorial" .

事後のデータ:

# Graph: http://example/bookStore
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/> .

<http://example/book3> dc:title "SPARQL 1.1 Tutorial" .
# Graph: http://example/bookStore2
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/> .

<http://example/book1> dc:title "Fundamentals of Compiler Design" .
<http://example/book1> dc:date "1996-01-01T00:00:00-02:00"^^xsd:dateTime .
<http://example/book1> a dcmitype:PhysicalObject .

<http://example/book4> dc:title "SPARQL 1.0 Tutorial" .
3.1.3.3 DELETE WHERE
DELETE WHERE  QuadPattern

DELETE WHEREオペレーションはDELETE/INSERTオペレーションの省略形で、WHERE句でマッチしたバインディングで、削除されるグラフのトリプルを定義するために用います。DELETE/INSERTと同じように、存在しないトリプルや存在しないグラフのトリプルを削除しても影響はなく、その結果は成功になるでしょう。

QuadPatternは、トリプルとグラフのマッチングのためのパターンと、削除用のテンプレートの両方として用いられます。QuadPattern内のTripleTemplateがGRAPH句の範囲に出現すれば、そのテンプレートがマッチしたグラフと、マッチしたトリプルが削除されるグラフが決まるでしょう。GRAPH句の範囲内にないTripleTemplateは、デフォルト・グラフにマッチするか削除されるでしょう。

例11:

この例のリクエストは、デフォルト・グラフから「Fred」という名を持つものに関するステートメントをすべて削除します。

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

DELETE WHERE { ?person foaf:givenName 'Fred';
                       ?property      ?value }

事前のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .
<http://example/fred> foaf:mbox  <mailto:fred@example> .

事後のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

例12:

この例のリクエストは、グラフhttp://example.com/namesの資源を「Fred」と命名しているステートメントと、グラフhttp://example/addressesにある、その資源に関するステートメントの両方を削除します（グラフhttp://example.com/namesの資源の一部には、グラフhttp://example/addressesに対応するトリプルがあると仮定して）。

PREFIX foaf:  <http://xmlns.com/foaf/0.1/>

DELETE WHERE {
  GRAPH <http://example.com/names> {
    ?person foaf:givenName 'Fred' ;
            ?property1 ?value1
  }
  GRAPH <http://example.com/addresses> {
    ?person ?property2 ?value2
  }
}

# Graph: http://example.com/names
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .
# Graph: http://example.com/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> foaf:mbox  <mailto:bill@example> .

<http://example/fred> foaf:mbox  <mailto:fred@example> .

事後のデータ:

# Graph: http://example.com/names
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .

# Graph: http://example.com/addresses
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> foaf:mbox  <mailto:bill@example> .

3.1.4 LOAD

LOADオペレーションは、IRIからRDFドキュメントを読み込み、グラフ・ストア内の指定されたグラフにそのトリプルを挿入します。指定された宛先グラフは、要求されれば作成されるべきです（SHOULD）。再び、一定のグラフに更新サービスを提供する実装は、認められていないグラフを作成するリクエストに失敗を返さなければなりません（MUST）。宛先グラフが既に存在していれば、そのグラフのデータは削除されないでしょう。

LOAD ( SILENT )? IRIref_from ( INTO GRAPH IRIref_to )?

IRIref_fromは、ストアがドキュメントを識別し、発見し、読み込むことができるよう、ドキュメントのIRIを指定します。最も一般的な形式は、httpIRIスキームを持つURLでしょう。ドキュメントが読み込まれれば、結果として生じるトリプルは、IRIref_toで参照しているIRIで指定された宛先グラフに挿入されるでしょう。

トリプルをロードするための宛先グラフのIRI（IRIref_to）が提供されていなければ、データはデフォルト・グラフにロードされるでしょう。

IRIref_fromで示されているIRIからRDFデータを検索できない場合（空のグラフが検索されるのとは対照的に）、または、検索方法によってエラー（例えば、HTTPエラー・コードなど）が返される場合、SPARQL 1.1更新サービスは失敗を返すべき（SHOULD）で、グラフ・ストアの状況は、リクエストを行う前と同じままであるべきです（SHOULD）。しかし、SILENTというキーワードが存在していれば、オペレーションは依然として成功を返し、グラフ・ストアの状況は現在のドキュメントによって指定されません。実装は、宛先グラフを作成することもしないこともあり、部分的なデータを受信するという送受信エラー（それ自体は、正当なRDFでありえる）の場合には、データを部分的にロードします。

3.1.5 CLEAR

CLEARオペレーションは、グラフ・ストア内で指定されているグラフのすべてのトリプルを削除します。

CLEAR  ( SILENT )? (GRAPH IRIref | DEFAULT | NAMED | ALL )

ここでは、DEFAULTキーワードは、グラフ・ストアのデフォルト・グラフのすべてのトリプルを削除するために用い、NAMEDキーワードは、グラフ・ストアのすべての名前付きグラフのすべてのトリプルを削除するために用い、ALLキーワードは、グラフ・ストアのすべてのグラフのすべてのトリプルを削除するために用います。GRAPHキーワードは、IRIrefで示されているグラフからすべてのトリプルを削除するために用います。このオペレーションでは、グラフ・ストアから空のグラフを削除することは必須ではありませんが、実装では、削除することを選択することもできます（MAY）。

# 指定されたグラフからすべてのトリプルを削除する。
CLEAR GRAPH IRIref

これは、原理的に、次と同じ影響を与えます。

# IRIrefで示されているIRIで指定されたグラフからすべてのトリプルを削除する。
DELETE { GRAPH IRIref { ?s ?p ?o } } WHERE { GRAPH IRIref { ?s ?p ?o } }

注:

他のグラフの和集合からデフォルト・グラフを生成するサービスの場合、CLEAR DEFAULTにはさらなる暗示があるかもしれませが、ここではそれは規定しないままにしておきます。

ストアに空のグラフの存在が記録されている場合、指定されたグラフが存在していなければ、SPARQL 1.1更新サービスは、デフォルトで失敗を返すべきです（SHOULD）。SILENTが存在していれば、オペレーションの結果は常に成功になるでしょう。

空のグラフが記録されていないストアは、常に成功を返すでしょう。

3.2 グラフ管理

グラフ管理オペレーションによって、グラフ・ストアの名前付きグラフを作成、破棄、移動、コピーしたり、あるグラフの内容を別のグラフに追加することが可能となります。グラフ・ストアに空の名前付きグラフの存在を記録することは必須ではないため、作成と破棄のオペレーションの結果がアクションになる必要はありません。

グラフ・ストアのデフォルト・グラフは、常に存在しています。

SPARQL 1.1更新は、次のグラフ管理オペレーションを提供します。

  • CREATEオペレーションは、空のグラフをサポートしているストアに新しいグラフを作成します。
  • DROPオペレーションは、グラフとその内容のすべてを削除します。
  • COPYオペレーションは、別のグラフのコピーを含むようにグラフを修正します。
  • MOVEオペレーションは、あるグラフから別のグラフにすべてのデータを移動させます。
  • ADDオペレーションは、あるグラフのすべてのデータを別のグラフへと再作成させます。

3.2.1 CREATE

このオペレーションは、グラフ・ストアにグラフを作成します。

CREATE ( SILENT )? GRAPH IRIref

空のグラフが記録されているストアの場合、これによって、IRIで指定されている名前を持つストアに新しい空のグラフが作成されるでしょう。グラフが既に存在していれば、SILENTキーワードが用いられている場合を除き、失敗を返すべきです（SHOULD）。いずれの場合も、既存のグラフの内容は変更されないままとなります。グラフが作成されなければ、SILENTキーワードが用いられている場合を除き、失敗を返さなければなりません（MUST）。

空の名前付きグラフが記録されていないストアは、存在しないグラフの作成時に常に成功を返すでしょう。

3.2.2 DROP

DROP  ( SILENT )? (GRAPH IRIref | DEFAULT | NAMED | ALL )

DROPオペレーションは、指定されたグラフ・ストアからグラフを削除します。GRAPHキーワードは、IRIrefで示されているグラフを削除するために用い、DEFAULTキーワードは、グラフ・ストアからデフォルト・グラフを削除するために用い、NAMEDキーワードは、グラフ・ストアからすべての名前付きグラフを削除するために用い、ALLキーワードは、グラフ・ストアからすべてのグラフを削除するため、つまり、ストアをリセットするために用います。このオペレーションが成功裡に完了した後、指定されたグラフは、それ以降のグラフ更新オペレーションにはもう利用できません。しかし、グラフ・ストアのDEFAULTグラフが削除されれば、実装は、削除後にそれを回復しなければなりません（MUST）。つまり、DROP DEFAULTはCLEAR DEFAULTと同等です。

ストアに空のグラフの存在が記録されている場合、指定された名前付きグラフが存在していなければ、SPARQL 1.1更新サービスは、デフォルトで失敗を返すべきです（SHOULD）。SILENTが存在していれば、オペレーションの結果は常に成功になるでしょう。

空のグラフが記録されていないストアは、常に成功を返すでしょう。

3.2.3 COPY

COPYオペレーションは、入力グラフから宛先グラフにすべてのデータを挿入するための省略形です。入力グラフのデータは影響を受けませんが、宛先グラフのデータは、それがもしあれば、挿入の前に削除されます。

COPY ( SILENT )? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT )

これは、オペレーション上、次と類似しています。

DROP SILENT (GRAPH IRIref_to | DEFAULT);
      INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } }

COPYとDROP/INSERTの組み合わせとの違いは、グラフを自身にコピーするためにCOPYを用いた場合には、オペレーションは実行されず、データは元のままであろうという点です。この状況でDROP/INSERTを用いると、結果は空のグラフになるでしょう。

宛先グラフが存在していなければ、作成されます。デフォルトでは、入力グラフが存在していない場合、サービスは失敗を返すことができます（MAY）。SILENTが存在していれば、オペレーションの結果は常に成功になるでしょう。

例13:

この例のリクエストは、デフォルト・グラフから名前付きグラフにすべてのステートメントをコピーします。

COPY DEFAULT TO <http://example.org/named>

事前のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .
# Graph http://example.org/named
<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .

事後のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .
# Graph http://example.org/named
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

http://example.org/namedの元の内容がCOPYオペレーションによって失われることに注意してください。

3.2.4 MOVE

MOVEオペレーションは、入力グラフから宛先グラフにすべてのデータを移動させるための省略形です。挿入後に入力グラフは削除され、宛先グラフのデータは、それがもしあれば、挿入前に削除されます。

MOVE (SILENT)? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT)

これは、オペレーション上、次と類似しています。

DROP SILENT (GRAPH IRIref_to | DEFAULT);
      INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } };
DROP ( GRAPH IRIref_from | DEFAULT)

MOVEとDROP/INSERT/DROPの組み合わせとの違いは、グラフを自身に移動させるためにMOVEを用いた場合には、オペレーションは実行されず、データは元のままであろうという点です。この状況でDROP/INSERT/DROPを用いると、その結果、グラフが削除されるでしょう。

宛先グラフが存在していなければ、作成されます。デフォルトでは、入力グラフが存在していない場合、サービスは失敗を返すことができます（MAY）。SILENTが存在していれば、オペレーションの結果は常に成功になるでしょう。

例14:

この例のリクエストは、デフォルト・グラフから名前付きグラフにすべてのステートメントを移動させます。

MOVE DEFAULT TO <http://example.org/named>

事前のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .
# Graph http://example.org/named
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/fred> a foaf:Person .
<http://example/fred> foaf:givenName "Fred" .

事後のデータ:

# Default graph

# Graph http://example.org/named
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

http://example.org/namedの元の内容がMOVEオペレーションによって失われることに注意してください。

3.2.5 ADD

ADDオペレーションは、入力グラフから宛先グラフにすべてのデータを挿入するための省略形です。入力グラフのデータは影響を受けず、宛先グラフの初期データは、それがもしあれば、手付かずのままとなります。

ADD ( SILENT )? ( ( GRAPH )? IRIref_from | DEFAULT) TO ( ( GRAPH )? IRIref_to | DEFAULT)

これは、次と同等です。

INSERT { ( GRAPH IRIref_to )? { ?s ?p ?o } } WHERE { ( GRAPH IRIref_from )? { ?s ?p ?o } }

宛先グラフが存在していなければ、作成されます。デフォルトでは、入力グラフが存在していない場合、サービスは失敗を返すことができます（MAY）。SILENTが存在していれば、オペレーションの結果は常に成功になるでしょう。

例15:

この例のリクエストは、デフォルト・グラフから名前付きグラフにすべてのステートメントを追加します。

ADD DEFAULT TO <http://example.org/named>

事前のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .
# Graph http://example.org/named
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/fred> a foaf:Person .

事後のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .
# Graph http://example.org/named
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

<http://example/fred> a foaf:Person .

<http://example/william> a foaf:Person .
<http://example/william> foaf:givenName "William" .
<http://example/william> foaf:mbox  <mailto:bill@example> .

4 SPARQL更新形式モデル

この項では、グラフ・ストアの変換に関する影響について記述することにより、更新オペレーションのセマンティクスを形式的に定義します。

4.1 一般的な定義

4.1.1 グラフ・ストア

定義: グラフ・ストア

グラフ・ストアGSは、RDFグラフの可変コンテナです。それには1つの名前のない（デフォルトの）スロットと、0以上の名前付きスロットがあります。名前のないスロットには、RDFグラフが格納されています。それぞれの名前付きスロットは、グラフと関連するIRIとの対です。グラフ・ストアは、可変のRDFデータセットと見ることができます。

GS = {DG, (iri1, G1), ... , (irin, Gn) }

この場合、次のとおりです。

  • デフォルト・グラフDGは、名前のないスロットに関連付けられているRDFグラフです。
  • n ≥ 0で、1 ≤ i ≤ nごとに、GiがIRI iriiで識別される名前付きスロットに関連付けられているRDFグラフです。
  • すべてのIRIは、個別的（distinct）です。つまり、i≠jはirii≠irijを意味します。

注:

このドキュメントでは、GSは、グラフ・ストアに対して用いますが、以後の定義では、同義的に、現在のグラフ・ストアの内容に対応したRDFデータセットに対しても用いることがあります。また、便宜上、以後の定義では中のGS = {DG, (iri1, G1), ... , (irin, Gn) }に対する数学表記の代わりに、GS = {DG} union {(irii, Gi) | 1 ≤ i ≤ n}と書く場合もあります。

4.1.2 抽象的な更新オペレーション

定義: 更新オペレーション

更新オペレーションOpは、引数Argsを受け入れ、グラフ・ストアGSを別のグラフ・ストアGS'に変換するアトミックなオペレーションで、次のとおりに表示されます。

Op(GS, Args) = GS'

「アトミックなオペレーション」とは、オペレーションがグラフ・ストア内で記述されている変換を、完全に実行するか、グラフ・ストアを変更しないまま実行するかのいずれかであることを意味します。つまり、結果は、GS'かGS（エラーの場合）のいずれかです。

更新オペレーションは、新しいスロットや新しいRDFグラフを作成したり、既存のスロットや対応するグラフを削除できます。各スロットの状況を個々に変更することもできます。

このドキュメントでは、この抽象的な更新オペレーションの定義の具体的なインスタンスに関して、個々の具体的な更新オペレーションのセマンティクスを定義しています。

4.2 補助的な定義

下記では、和集合を作成するための補助関数と基本的なオペレーション、そして、RDFデータセットの違いを提示しています。具体的な更新オペレーションは、その基本的なオペレーションの観点で定義されるでしょう。

注:

次の定義では、個々の集合演算（和集合、積集合、差集合）を示すために「和集合」、「積集合」、「マイナス」と記述しています。

4.2.1 データセット-UNION

この基本的なオペレーションは、2つのRDFデータセットの和集合を作成します。

定義: データセット-UNION

DS={DG} union {(irii, Gi) | 1 ≤ i ≤ n}とDS' = {DG'} union {(iri'j, G'j) | 1 ≤ j ≤ m}を2つのRDFデータセットとします。 さらに、graphNames(DS) = { irii | 1 ≤ i ≤ n}とし、graphNames(DS') = {iri'j | 1 ≤ j ≤ m}とします。 DSとDS'の間のデータセット-UNIONは、次のとおりに定義されます。

Dataset-UNION(DS, DS') = {DG union DG'} union {(iri, G) | iri in graphNames(DS) union graphNames(DS')}

そして、Gは次のとおりに定義されます。

  • Gi for iri = irii such that irii in graphNames(DS) minus graphNames(DS')
  • Gj for iri = iri'j such that irij in graphNames(DS') minus graphNames(DS)
  • Gi union Gj for iri = irii = iri'j in graphNames(DS) intersect graphNames(DS')

このとき、グラフ間の和集合は、それらのグラフのトリプルの和集合と定義されています。

注:

以下で、Dataset-UNION( X ) where X = {DS1,DS2,... ,DSn}がデータセットの集合であると記述している場合には常に、これはDataset-UNION(DS1, Dataset-UNION(DS2, ... , Dataset-UNION(DSn,{})...))に対する省略形であるという理解によるものであることに注意してください。

4.2.2 データセット-DIFF

このオペレーションは、与えられたデータセットのトリプルを別のデータセットから削除します。

定義: データセット-DIFF

DS={DG} union {(irii, Gi) | 1 ≤ i ≤ n}とDS' = {DG'} union {(iri'j, G'j) | 1 ≤ j ≤ m})を2つのRDFデータセットとします。さらに、graphNames(DS) = { irii | 1 ≤ i ≤ n}とし、graphNames(DS') = {iri'j | 1 ≤ j ≤ m}とします。DSとDS'の間のデータセット-DIFFは、次のとおりに定義されます。

Dataset-DIFF(DS, DS') = {DG minus DG'} union { (iri, G) | iri in graphNames(DS) })

そして、Gは次のとおりに定義されます。

  • Gi for iri = irii such that irii in graphNames(DS) minus graphNames(DS')
  • Gi minus G'j for iri = irii = iri'j in graphNames(DS) intersect graphNames(DS')

このとき、Gi minus G'jは、2つのグラフのトリプルの集合の差集合と定義されています。

4.2.3 Dataset( QuadPattern, μ, DS, GS )

次の補助関数は、ソリューション・マッピングとRDFデータセットを与えられた場合に、QuadPatternからRDFデータセットを構築します。

μをa solution mappingとし、DS={DG} union {(irii, Gi) | 1 ≤ i ≤ n}をRDFデータセットとし、GSをグラフ・ストアの現在の状況とします。例えば、DSを修正するためにUSING [NAMED]の用いているため、DSはGSとは異なるものとして区別されます。

形式のQuadPatternについて

  • '{}'

    Dataset(QuadPattern, μ, DS, GS ) = {{}} つまり、空のデフォルト・グラフのみで構成される空のデータセット。

  • '{' TriplesTemplate? '}'

    Dataset(QuadPattern, μ, DS, GS )は、変数をskμ(TriplesTemplate)に代用して得られた、すべて有効なRDFのトリプルから成るデフォルト・グラフのみで構成されるデータセットで、μに従い、また、和集合によってこれらのトリプルを1つのRDFグラフに組み合わせます。

  • 'GRAPH' VarOrIri '{' TriplesTemplate? '}'

    Dataset(QuadPattern, μ, DS, GS )は、空のデフォルト・グラフと、それに加えて、μ(VarOrIri)が有効なIRIを生成した場合には、Gが、変数をskμ(TriplesTemplate)に代用して得られた、すべて有効なRDFのトリプルから成るような名前付きグラフ(μ(VarOrIri)とで構成されるデータセットで、μに従い、また、和集合によってこれらのトリプルを1つのRDFグラフに組み合わせます。

  • '{' QuadPattern1 QuadPattern2 '}'

    Dataset(QuadPattern, μ , DS, GS ) = Dataset-UNION ( Dataset(QuadPattern1, μ, DS, GS ) , Dataset(QuadPattern2, μ, DS, GS ) )

ここでは、skμ(TriplesTemplate)は、TriplesTemplateに出現する空白ノードを、新しい一意の空白ノード（現在の更新リクエストと個々のμに対して一意で、DSまたはGSで使用される任意の空白ノードとは異なる）と入れ替えるということを表します。

関数skμは、QuadPatternの「新しい」空白ノードのインスタンスが、μという「1つのソリューションによって」（SPARQL 1.1クエリ言語のCONSTRUCTテンプレートの空白ノードの処理と同じように）再び作成されることを保証します。SPARQL文法のリクエスト内の空白ノードのスコーピングに関する個々の言及も参照してください。

4.2.4 Dataset( QuadPattern, P, DS, GS )

次の補助関数は、グラフ・パターンとRDFデータセットを与えられた場合に、QuadPatternからRDFデータセットを構築します。

Pをグラフ・パターンとし、DS={DG} union {(irii, Gi) | 1 ≤ i ≤ n}をRDFデータセットとし、GSをグラフ・ストアの現在の状況とします。その場合、次のとおりです。

Dataset(QuadPattern, P, DS, GS ) = Dataset-UNION( { Dataset(QuadPattern, μ, DS, GS) | μ in eval'(DS(DG),P) } )

つまり、μがデータセットDSに対するPのソリューション内にあるようなすべてのμに対する和集合。

ここでは、eval'()は、ただ1つの例外を除いて、SPARQL 1.1クエリ言語の評価関数eval()と全く同じように、SPARQL 1.1クエリのBGPマッチングの空白ノードの処理とは対照的に、ここでは、BGPマッチングに用いられたスコーピング・グラフSGは、アクティブ・グラフと同等であると定義されています。つまり、アクティブ・グラフの空白ノードは、ソリューション内で維持されています。

eval'()の定義は、DS内で共通参照を行う空白ノードが、パターン評価の間に「失われ」ないことを保証します。SPARQL 1.1クエリの空白ノードの処理を参照してください。後者は、トリプルを削除/追加するために、DSの空白ノードがGSの既存の空白ノードにマッチング可能であることを保証するために必要です。グラフ・ストア内の既存の空白ノードに対するマッチングについて説明するために、次の更新リクエストでは、空白ノードを主語として持つすべてのトリプルを削除します。

DELETE { ?S ?P ?O . } WHERE { ?S ?P ?O . FILTER ( isBlank(?S)) }

事前のデータ:

# Default graph
@prefix :      <http://example.com/> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

_:b a foaf:Person .
:s  a foaf:Person .

事後のデータ:

# Default graph
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

:s  a foaf:Person .

4.3 グラフ更新オペレーション

4.3.1 データ挿入オペレーション

定義: データ挿入オペレーション

Insert Dataオペレーションは、新しいトリプル（（基底）QuadPatternとして与えられる）が、グラフ・ストアGS（デフォルト・スロットか名前付きスロット）に追加される更新オペレーションです。

OpInsertData(GS, QuadPattern) = Dataset-UNION(GS, Dataset(QuadPattern,{},GS,GS))

この場合、{}は空のソリューション・マッピングです。

4.3.2 データ削除オペレーション

定義: データ削除オペレーション

Delete DataオペレーションOpDeleteDataは、トリプル（（基底）QuadPatternとして与えられる）がグラフ・ストアGS（デフォルト・スロットか名前付きスロット）から削除される更新オペレーションです。

OpDeleteData(GS, QuadPattern) = Dataset-DIFF(GS, Dataset(QuadPattern,{},GS,GS))

この場合、{}は空のソリューション・マッピングです。

4.3.3 削除・挿入オペレーション

定義: 削除・挿入オペレーション

Delete InsertオペレーションOpDeleteInsertは、(1)トリプルが、グラフ・ストアGS（デフォルト・スロットか名前付きスロットのいずれか）から削除され、その後、(2)新しいトリプルが、グラフ・ストアGS（デフォルト・スロットか名前付きスロットのいずれか）に追加される更新オペレーションです。削除される（または挿入される）トリプルは、DSに対するグループ・グラフ・パターンPのパターン・ソリューションを、QuadPattern QuadPatternDEL（またはQuadPatternINS）に適用することにより識別されます。

OpDeleteInsert(GS, DS, QuadPatternDEL, QuadPatternINS, P) = Dataset-UNION(Dataset-DIFF(GS, Dataset(QuadPatternDEL,P,DS,GS)), Dataset(QuadPatternINS, P,DS,GS)

4.3.4 ロード・オペレーション

定義: ロード・オペレーション

LoadオペレーションOpLoadは、（離れたグラフの）新しいトリプルがグラフ・ストア（デフォルト・スロットか名前付きスロットのいずれか）に（指定されていれば）追加される更新オペレーションです、

OpLoad(GS, documentIRI) = Dataset-UNION(GS, { graph(documentIRI) } )

OpLoad(GS, documentIRI, iri) = Dataset-UNION(GS, { {}, (iri,graph(documentIRI)) } )

この場合、graph(documentIRI)は、IRI documentIRIから検索されたRDFドキュメントによってシリアル化を行ったRDFグラフを返す関数で、その場合、検索されたグラフの中に存在する空白ノードは「標準化分離」（standardized apart）であると想定されます。つまり、ロードしたグラフの空白ノードは、グラフ・ストアGSに既に存在する空白ノードと素である必要があります。

4.3.5 クリア・オペレーション

定義: クリア・オペレーション

ClearオペレーションOpClearは、トリプルがグラフ・ストア（名前付きスロット、デフォルト・スロット、すべての名前付きスロット、すべてのスロットのいずれか）から削除される更新オペレーションです。クリア・オペレーションには、名前付きグラフをクリアするためのOpClear、デフォルト・グラフをクリアするためのOpCleardef 、すべての名前付きグラフをクリアするためのOpClearnamed、デフォルト・グラフを含むすべてのグラフをクリアするためのOpClearallというバリエーションがあります。

GS = {DG} union {(irii, Gi) | 1 ≤ i ≤ n}とし、graphNames(GS) = { irii | 1 ≤ i ≤ n}とすると、次のとおりです。

OpClear(GS, iri) = GS if iri not in graphNames(GS); otherwise, OpClear(GS, irij) = ( GS minus {(irij, Gj)} ) union {(irij,{})}, where (irij, Gj) ∈ GS and iri = irij

OpCleardef(GS) = {{}} union {(irii, Gi) | 1 ≤ i ≤ n}

OpClearnamed(GS) = {DG} union {(irii, {}) | 1 ≤ i ≤ n}

OpClearall(GS) = {{}} union {(irii, {}) | 1 ≤ i ≤ n}

注:

グラフ・ストアが空のままのグラフを削除できるため、そのようなグラフ・ストアでは、名前付きグラフで実行したクリア・オペレーションには、削除オペレーションが直後に続くように見えるかもしれません。下記を参照してください。

4.4 グラフ管理オペレーション

4.4.1 作成オペレーション

定義: 作成オペレーション

CreateオペレーションOpCreateは、(1)新しい名前付きスロットと(2)新しいグラフGが、グラフ・ストアで作成される更新オペレーションです。新しいグラフは、新しいスロットに格納され、空です。他のスロットとグラフは影響を受けません。

GS = {DG} union {(irii, Gi) | 1 ≤ i ≤ n}とし、graphNames(GS) = { irii | 1 ≤ i ≤ n}とすると、次のとおりです。

OpCreate(GS, iri) = GS union {(iri, {})} if iri not in graphNames(GS); otherwise, OpCreate(GS, iri) = GS

注:

グラフ・ストアが空のままのグラフを削除できるため、そのようなグラフ・ストアでは、空または存在しないグラフで実行した作成オペレーションには、削除オペレーション（次の小項目を参照）が暗黙的に直後に続くように、または単純に影響のないオペレーションのように見えるかもしれません。

4.4.2 削除オペレーション

定義: 削除オペレーション

DropオペレーションOpDropは、1つ以上のスロット（名前付きスロットirii、デフォルト・スロット、すべての名前付きスロット、またはすべてのスロット）とそれに対応するグラフが、グラフ・ストアから削除される更新オペレーションです。削除オペレーションには、名前付きグラフを削除するためのOpDrop、デフォルト・グラフを削除するためのOpDropdef（デフォルト・グラフを削除できないけれども、それを削除することは、クリアすることを意味するに過ぎないため、OpCleardefと同等です）、すべての名前付きグラフを削除するためのOpDropnamed、デフォルト・グラフを含むすべてのグラフを削除するためのOpDropallというバリエーションがあります。

GS = {DG} union {(irii, Gi) | 1 ≤ i ≤ n}とし、graphNames(GS) = { irii | 1 ≤ i ≤ n}とすると、次のとおりです。

OpDrop(GS, iri) = GS if iri not in graphNames(GS); otherwise, OpDrop(GS, irij) = {DG} union {(irii, Gi ) | i ≠ j and 1 ≤ i ≤ n} where iri = irij

OpDropdef(GS) = OpCleardef(GS)

OpDropnamed(GS) = {DG}

OpDropall(GS) = {{}}

4.5 形式モデルへの更新リクエストのマッピング

この項では、SPARQL 1.1更新言語の更新リクエストを、この項の最初の部分で定義しているグラフ・ストア上の更新オペレーションにマッピングする方法を示しています。このマッピングは、すべての更新リクエストにおいて、PREFIXが拡張されていると仮定します。さらに、WITH句は、後続するDELETE句とINSERT句内のQuadPatternと、USINGとUSING NAMEDがない場合には、後続するWHERE句内のGroupGraphPatternの両方を、GRAPHパターンにラップすることで置き換えられたと想定します。

リクエストから更新オペレーションへのマッピングは、入力としてGraphstore GS（リクエストの実行前に）と更新リクエストRをとり、次のテーブルで示している更新オペレーションの呼び出しへと拡張する、再帰的な置換関数Tr(GS,R)の観点で定義されています。COPY、MOVEとADDのオペレーションについては、これらは省略形であると理解されているため、ここでは明示的に言及しません。

表1: 更新リクエストから更新オペレーションへのマッピング
更新リクエストR Tr(GS,R) =
R1 ; R2 Tr(Tr(GS, R1), R2)
INSERT DATA QuadData OpInsertData(GS, QuadData)
DELETE DATA QuadData OpDeleteData(GS, QuadData)
DELETE QuadPatternDEL INSERT QuadPatternINS
UsingClause*
WHERE GroupGraphPattern		 OpDeleteInsert(GS, TrDataset(GS,UsingClause*), QuadPatternDEL, QuadPatternINS, GroupGraphPattern)
DELETE QuadPatternDEL
UsingClause*
WHERE GroupGraphPattern		 OpDeleteInsert(GS, TrDataset(GS,UsingClause*), QuadPatternDEL, {}, GroupGraphPattern)
INSERT QuadPatternINS
UsingClause*
WHERE GroupGraphPattern		 OpDeleteInsert(GS, TrDataset(GS,UsingClause*), {}, QuadPatternINS, GroupGraphPattern)
DELETE WHERE QuadPattern OpDeleteInsert(GS, GS, QuadPattern, {}, QuadPattern)
LOAD (SILENT)? IRIref OpLoad(GS, IRIref)
LOAD (SILENT)? IRIreffrom INTO GRAPH IRIrefto OpLoad(GS, IRIreffrom, IRIrefto)
CLEAR (SILENT)? GRAPH IRIref OpClear(GS, IRIref)
CLEAR (SILENT)? DEFAULT OpCleardef(GS)
CLEAR (SILENT)? NAMED OpClearnamed(GS)
CLEAR (SILENT)? ALL OpClearall(GS)
CREATE (SILENT)? GRAPH IRIref OpCreate(GS, IRIref)
DROP (SILENT)? GRAPH IRIref OpDrop(GS, IRIref)
DROP (SILENT)? DEFAULT OpDropdef(GS)
DROP (SILENT)? NAMED OpDropnamed(GS)
DROP (SILENT)? ALL OpDropall(GS)

この表は、USING句とUSING NAMED句のオプションの集合からデータセットを構築する1つの補助置換関数TrDataset()を用いており、次のとおりに定義されます。

表2: RDFデータセットへのUsingClauseのマッピング
置換関数 定義
TrDataset(GS,UsingClause*) =
  • 空でない場合には、UsingClauseで記述されたRDFデータセットDS
  • それ以外の場合には、GSの現在の状況に対応するRDFデータセット

注:

USING句とUSING NAMED句からどのくらい正確にRDFデータセットを得られるか（例えば、グラフ名IRIを逆参照してそれらの検索を試みることにより、または、既存のグラフ・ストアからそれらのグラフを選択することにより）は、実装に依存します。特に、この仕様では、SPARQL 1.1クエリ言語仕様のRDFデータセットの指定の項の、類似するFROM句とFROM NAMED句に対する検討の範囲を超える空白ノードの同一性に関する仮定を強制しません。

5 適合性

SPARQL更新の文字列の適合性に関しては、付録BのSPARQL 1.1更新文法を参照してください。

この仕様は、SPARQL 1.1グラフ・ストアHTTPプロトコルおよびSPARQL 1.1 RDF用プロトコルとの併用を意図しています。

A セキュリティに関する留意点（参考情報）

更新用のRDFデータを公開すると、あらゆる開発において認識し、付随する危険について考慮しなければならない多くのセキュリティ上の課題が発生します。この提案では、一部の潜在的な課題について議論します。定期的に新しいセキュリティの課題が発見され、個々の実装は自身の懸案事項を取り入れています。したがって、実装者は、これが考えられる課題を含んだ部分的なリストにすぎず、完全で正式なものと考えることはできないことを知っているべきです。

B インターネット・メディア・タイプ、ファイル拡張子、およびマッキントッシュ・ファイル・タイプ

SPARQL更新言語のインターネット・メディア・タイプ/MIMEタイプは、「application/sparql-update」です。

SPARQL更新ファイルは、すべてのプラットフォーム上で拡張子「.ru」（小文字）であることが推奨されます。

マッキントッシュHFSファイル・システム上に保存されたSPARQL更新ファイルには、ファイル・タイプ「TEXT」が付与されていることが推奨されます。

タイプ名:
application
サブタイプ名:
sparql-update
必須パラメータ:
なし
任意のパラメータ:
なし
コード化に関する留意点:
SPARQL更新言語の構文は、Unicode[UNICODE]のコード・ポイントで表されます。コード化は、常にUTF-8[RFC3629]です。
Unicodeコード・ポイントは、Xが16進の[0-9A-F]である場合、\uXXXX（U+0～U+FFFF）または\UXXXXXXXX構文（U+10000以降）を用いて表現できます。
セキュリティに関する留意点:
SPARQL更新付録A、セキュリティに関する留意点およびRFC 3629[RFC3629]の7項、セキュリティに関する留意点を参照してください。
互換性に関する留意点:
互換性の問題は知られていません。
公開済み仕様書:
この仕様書。
このメディア・タイプを使用するアプリケーション:
現時点でこのメディア・タイプを使用するアプリケーションは知られていません。
追加情報:
マジック・ナンバー:
SPARQLクエリは、ドキュメントの冒頭付近に、文字列「PREFIX」（大文字と小文字を区別しない）を持つことができます。
ファイル拡張子:
「.ru」
基底IRI:
SPARQL「BASE <IRIref>」用語は、現在の基底IRIを、ドキュメントにおいて後ほど順次使用されるクエリ言語内の相対IRIrefに変更できます。
マッキントッシュ・ファイル・タイプ・コード:
「TEXT」
詳細情報に関する連絡先:
public-rdf-dawg-comments@w3.org
意図する用途:
汎用
使用上の制限:
なし
著者／改版管理者:
SPARQL 1.1仕様は、ワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium）のSPARQLワーキンググループ（SPARQL Working Group）の作業の成果です。W3Cは、これらの仕様の変更に対する管理権を有します。

C SPARQL 1.1更新文法

SPARQL 1.1更新文法の形式的な定義は、SPARQL 1.1クエリ文法で提供しています。これは、SPARQL 1.1更新の文法が、その構造のほとんどをSPARQL 1.1クエリと共有するためです。

D 参考文献

D.1 規範的な参考文献

IANA-CHARSETS
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)
RFC3987
Internationalized Resource Identifiers (IRIs), M. Durst , M. Suignard (See http://www.ietf.org/rfc/rfc3987.txt.)
RDF-MT
RDF Semantics, P. Hayes, Editor, W3C Recommendation, 10 February 2004, see http://www.w3.org/TR/2004/REC-rdf-mt-20040210/, Latest version available at http://www.w3.org/TR/rdf-mt/. (See http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.)

D.2 その他の参考文献

Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Bruggemann-Klein
Bruggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Bruggemann-Klein and Wood
Bruggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universitat Freiburg, Institut fur Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Clark
James Clark. Comparison of SGML and XML. (See http://www.w3.org/TR/NOTE-sgml-xml-971215.)
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of Language Tags (See http://www.iana.org/assignments/language-subtag-registry.)
IETF RFC 2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (See http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 3023
IETF (Internet Engineering Task Force). RFC 3023: XML Media Types. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)
IETF RFC 3629
IETF (Internet Engineering Task Force). RFC 3629: UTF-8, a transformation format of ISO 10646, F. Yergeau. November 2003. (See http://www.ietf.org/rfc/rfc3629.txt.)
ISO 639
(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166
(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions ― Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing ― Text and Office Systems ― Standard Generalized Markup Language (SGML). First edition ― 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology ― Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
UNICODE
The Unicode Consortium. The Unicode Standard, Version 5.0.0. Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0. (See http://www.unicode.org/unicode/standard/versions/.)
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology ― Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879/n0029.htm.)
XML Names
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/xml-names/.)

変更履歴

勧告案以後の変更履歴

最終草案以後の変更履歴