要約

リンクト・データ・パッチ・フォーマット（LDパッチ）は、リンクト・データ資源にパッチを行うための一連のオペレーションを表現するための言語を定義しており、これは、HTTP PATCHメソッドで用いる場合に適しています。

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

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

リンクト・データ・プラットフォーム（LDP）ワーキンググループは、現在LDパッチを支持していますが、LDP RDF情報源におけるLDP PATCH[LDP]オペレーションに用いるために、どのフォーマットを促進すべきかを決定するためのさらなるインプットを探しています。実行可能な候補には、他に次のものがあります。

現時点では、シンプルさ、実装の容易性、予期されるデータのラン・タイム性能の点において、LDパッチが優位です。この決定に関連するデータを歓迎します。

この仕様は、以前に勧告候補（CR）として公表されました。現在の憲章のもとで残された時間内にCRの終了基準を満たすには実装が不十分であったため、ワーキンググループは、W3C勧告トラックから外し、将来の参照のためにW3Cノートとして公表することにしました。このドキュメントは、部分的または全体的に、将来別のWGが再利用できるかもしれませんし、できないかもしれません。

このドキュメントは、リンクト・データ・プラットフォーム・ワーキンググループによってワーキンググループ・ノートとして発表されました。このドキュメントに関してコメントを行いたい場合には、public-ldp-comments@w3.org（購読、アーカイブ）にお送りください。どのようなコメントでも歓迎します。

ワーキンググループ・ノートとしての公開は、W3Cメンバーによる承認を意味するものではありません。これは草案ドキュメントであるため、他のドキュメントによって、随時更新されたり、置き換えられたり、廃止されることもありえます。このドキュメントを「作業中」以外のものとして引用することは適当ではありません。

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

このドキュメントは、2014年8月1日のW3Cプロセス・ドキュメントによって管理されています。

目次

1. はじめに

この項は非規範的です。

リンクト・データは、構造化されたデータが、リンクされ、より便利になるように公開する方法です。これは、HTTP、RDF、IRIなどの標準的なウェブ技術を基に構築されますが、人間の読者にウェブ・ページを提供するために用いるのではなく、コンピュータが機械的に読むことができる方法で情報を共有するために拡張を行っています。これにより、様々な情報源のデータが接続され、クエリを実行することが可能となります。（Wikipediaより）。

このドキュメントでは、リンクト・データに適用する変更点を記述するためのフォーマットであるリンクト・データ・パッチ・フォーマット（LDパッチ）を定義しています。これは、ウェブ資源に部分的な修正を行うためのメソッドであるHTTP PATCH[RFC5789]と共に用いるのに適しています。

LDパッチ言語（または、LDパッチ・ドキュメント）の実例は、リンクト・データ資源に対して実行されるオペレーション、つまり、その資源を表しているグラフに対するRDF[rdf11-concepts]トリプルの追加または削除を定義しています。

このドキュメントで説明しているLDパッチ・フォーマットは、資源を中心としてRDFグラフを更新するための言語と捉えるべきです。これには、空白ノードに対する部分的なサポートとrdf:Listの操作により、その表現力をRDFの差分の範囲に限定する意図があります。LDP WGは、RDFグラフとクアッド・ストアに関するより強力なオペレーションについては、SPARQL更新[sparql11-update]を読むことを検討するように推奨します。

2. 例

この項は非規範的です。

2.1 完全な例

下記のRDFグラフは、ティム・バーナーズ・リーという名前の人物（<http://example.org/timbl#>で示される）と彼が出席した2つのイベントとの関係を記述しています。

例1
@prefix schema: <http://schema.org/> .
@prefix profile: <http://ogp.me/ns/profile#> .
@prefix ex: <http://example.org/vocab#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<#> a schema:Person ;
  schema:alternateName "TimBL" ;
  profile:first_name "Tim" ;
  profile:last_name "Berners-Lee" ;
  schema:workLocation [ schema:name "W3C/MIT" ] ;
  schema:performerIn _:b1, _:b2 ;
  ex:preferredLanguages ( "en" "fr" ).

_:b1 schema:name "F2F5 - Linked Data Platform" ;
  schema:url <https://www.w3.org/2012/ldp/wiki/F2F5> .

_:b2 a schema:Event ;
  schema:name "TED 2009" ;
  schema:startDate "2009-02-04" ;
  schema:url <http://conferences.ted.com/TED2009/> .

下記は、HTTPパッチ・リクエストの例で、LDパッチ・ドキュメントを表します。

例2
PATCH /timbl HTTP/1.1
Host: example.org
Content-Length: 478
Content-Type: text/ldpatch
If-Match: "abc123"

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .
@prefix profile: <http://ogp.me/ns/profile#> .
@prefix ex: <http://example.org/vocab#> .

Delete { <#> profile:first_name "Tim" } .
Add {
  <#> profile:first_name "Timothy" ;
    profile:image <https://example.org/timbl.jpg> .
} .

Bind ?workLocation <#> / schema:workLocation .
Cut ?workLocation .

UpdateList <#> ex:preferredLanguages 1..2 ( "fr-CH" ) .

Bind ?event <#> / schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ]  .
Add { ?event rdf:type schema:Event } .

Bind ?ted <http://conferences.ted.com/TED2009/> / ^schema:url ! .
Delete { ?ted schema:startDate "2009-02-04" } .
Add {
  ?ted schema:location [
    schema:name "Long Beach, California" ;
    schema:geo [
      schema:latitude "33.7817" ;
      schema:longitude "-118.2054"
    ]
  ]
} .

この例では、@prefixおよび接頭辞名、 Add（追加）、Delete（削除）、Cut（切り取り）、ノード・バインディングのメカニズムであるUpdateListオペレーション、空白ノードの作成といった、LDパッチ・フォーマットのほとんどの機能を紹介しています。このようなLDパッチ・ドキュメントを識別するために、「text/ldpatch」というメディア・タイプが将来に用いられるでしょう。

以下は、（パッチが実行された）結果のドキュメントです。

例3
@prefix schema: <http://schema.org/> .
@prefix profile: <http://ogp.me/ns/profile#> .
@prefix ex: <http://example.org/vocab#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<#> a schema:Person ;
  schema:alternateName "TimBL" ;
  profile:first_name "Timothy" ;
  profile:last_name "Berners-Lee" ;
  profile:image <https://example.org/timbl.jpg> ;
  schema:performerIn _:b1, _:b2 ;
  ex:preferredLanguages ( "en" "fr-CH" ) .

_:b1 a schema:Event ;
  schema:name "F2F5 - Linked Data Platform" ;
  schema:url <https://www.w3.org/2012/ldp/wiki/F2F5> .

_:b2 a schema:Event ;
  schema:name "TED 2009" ;
  schema:url <http://conferences.ted.com/TED2009/> ;
  schema:location [
    schema:name "Long Beach, California";
    schema:geo [ schema:latitude "33.7817" ; schema:longitude "-118.2054" ]
  ] .

2.2 rdf:List操作の例

この項のLDパッチのすべての例は、下記のRDFグラフに対して適用されたものです（ターゲットIRIはhttp://example.org/timbl）。

例4
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "ipsum" "dolor" "sit" "amet" ) .

要素を置き換える方法

この例では、1つの要素（ここでは、2番目の要素）を新しい要素に置き換える方法を示します。

例5
UpdateList <#> <http://example.org/vocab#preferredLanguages> 1..2 ( "fr" ) .

生成されるグラフ:

例6
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "fr" "dolor" "sit" "amet" ) .

新しい要素を挿入する方法

この例では、特定のインデックス番号（ここでは2）の位置に新しい要素を挿入する方法を示します。

例7
UpdateList <#> <http://example.org/vocab#preferredLanguages> 2..2 ( "en" "fr" ) .

生成されるグラフ:

例8
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "ipsum" "en" "fr" "dolor" "sit" "amet" ) .

要素を追加する方法

この例では、コレクション（集合）の最後に要素を追加する方法を示します。

例9
UpdateList <#> <http://example.org/vocab#preferredLanguages> .. ( "en" "fr" ) .

生成されるグラフ:

例10
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "ipsum" "dolor" "sit" "amet" "en" "fr" ) .

あるインデックス番号以後の全要素を置き換える方法

この例では、インデックス番号2以後のすべての要素を、提供されたコレクションに置き換える方法を示します。

例11
UpdateList <#> <http://example.org/vocab#preferredLanguages> 2.. ( "en" "fr" ) .

生成されるグラフ:

例12
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "ipsum" "en" "fr" ) .

最後の要素を置き換える方法

この例では、提供されたコレクションの最後の3つの要素を置き換える方法を示します。

例13
UpdateList <#> <http://example.org/vocab#preferredLanguages> -3.. ( "en" "fr" ) .

生成されるグラフ:

例14
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "ipsum" "en" "fr" ) .

要素を削除する方法

この例では、コレクションから要素（ここでは、2番目と3番目）を削除する方法を示します。

例15
UpdateList <#> <http://example.org/vocab#preferredLanguages> 1..3 ( ) .

生成されるグラフ:

例16
<#> <http://example.org/vocab#preferredLanguages> ( "lorem" "sit" "amet" ) .

コレクションを空にする方法

最後に、この例では、コレクションを空にする方法を示します。

例17
UpdateList <#> <http://example.org/vocab#preferredLanguages> 0.. ( ) .

生成されるグラフ:

例18
<#> <http://example.org/vocab#preferredLanguages> ( ) .

3. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

「しなければならない（MUST）」、「してはならない（MUST NOT）」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。

この仕様では、次に対する適合性基準を定義しています。

適合LDパッチ・ドキュメントは、具象構文の項で定義している文法に準拠したUnicode文字列です。

適合LDパッチ・パーサは、LDパッチ・ドキュメントを解析できるシステムです。その結果として作成される抽象概念は、リンクト・データ・パッチ、または、文脈上明白な場合には単にパッチと呼ばれます。パーサは、リテラルを、字句形式、および、オプションの言語タグ[BCP47]（Turtle[Turtle]で用いられているもの）またはデータ型IRIで構成されているとみなすべきです。

適合LDパッチ・プロセッサは、RDFグラフに対してリンクト・データ・パッチを実行でき、そのセマンティクスが、LDパッチ・セマンティクスの項の定義に従っているシステムです。それは、新しいグラフを返すか、インプットのグラフの置き換え更新を行います。

適合LDパッチ・サーバーは、LDP PATCH[LDP]で定義されているとおりにHTTP PATCHリクエストによりLDパッチ・ドキュメントを処理できるシステムです。それは、エラー処理の項で定義されているとおりにエラーを処理できなければなりません（MUST）。

LDパッチ・フォーマットを識別するIRIは、http://www.w3.org/ns/formats/LD_Patchです。

4. LDパッチのセマンティクス

LDパッチ・ドキュメントは、IRI（ターゲットIRI）で識別されるリンクト・データ資源に適用され、RDFグラフ（ターゲット・グラフ）で表されます。それは、プロローグとそれに続くステートメントのリストで構成されています。プロローグでは、IRIをPrefixedNameとして省略するために用いる幾つかの接頭辞を宣言します。その後、個々のステートメントは、ターゲット・グラフのマッチするノードに変数をバインドするか、ターゲット・グラフの変更点を指定します。

4.1 ノードとトリプルのセマンティクス

LDパッチは、ノードとトリプルの記述に関し、その多く構文とセマンティクスをTurtle[Turtle]から借用しています。特に、生成規則のトリプルやコレクションを用いるときには常に、引数グラフと呼ばれるトリプルとしてそれらを解析するためにTurtleのセマンティクスを適用しなければなりません。

しかし、Turtleと比べると、LDパッチが引数グラフを解析する方法には、取り上げるべきポイントが少しあります。

IRIとRDFリテラルはグローバルなスコープを持っているため、引数グラフ内のそのようなノードは、ターゲット・グラフ内と同じ資源を表します。一方で、空白ノードはグローバルな識別子を持たないため、問題が生じます。実際に、 空白ノード識別子の範囲は、それが出現するLDパッチ・ドキュメントに制限されるため、LDパッチ・ドキュメントに出現する空白ノード識別子は、ターゲット・グラフに元々存在していた任意のノードではなく、新しい空白ノードを表すと理解されます。したがって、LDパッチの空白ノード識別子は、ターゲット・グラフ内の既存の空白ノードに干渉することができません。

しかし、LDパッチは、これらの既存の空白ノードに対応するためのメカニズムを提供します。そのメカニズムとは、パス式で到達可能な空白ノードに変数をバインドするか、空白ノードで構成されるツリー全体をカットするか、RDFコレクションを構成しているそれらの空白ノードをUpdateListで処理するかです。これらのメカニズムが、与えられた空白ノードに明確に対応できない場合もありますが、それは異常なケースと考えられており、この仕様の範囲外です。

4.2 パス式

パス式は、ターゲット・グラフ内のRDFノードの位置を示すために使用できます。パス式は、連続する1つ以上のステップ（「/」が挿入される）や制約で構成され、左から右の順に適用されます。その主な目的は、以前に識別されたノードからグラフのアークを「移動」することにより空白ノードに対応できるようにすことです。

/は、左側の演算子がノード・セット、右側のオペランドがステップ、結果がノード・セットである、左側と関連を持つオペレータのように動作します。制約は、暗黙のパラメータが、それが適用されるノード・セットである述語関数のように動作します。フィルタの文脈では、この暗黙のノード・セットは/に対する左オペランドになります。

ステップは、次の3種類でありえます。

制約は、次の2種類でありえます。

下記のパス式（例の項から抜粋）により、schema:performerInという述語とマッチするすべてのイベントが検索され、<https://www.w3.org/2012/ldp/wiki/F2F5>というIRIとマッチするもののみが保持されます 。

例19
/ schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ]

4.3 Patchオペレーション

4.3.1 Bind

Bindオペレーションは、RDF用語を変数にバインドするために用いられます。このプロセスの結果、きっかり1つのノードにバインドされた変数が作成されます。バインド後、変数はその後のステートメントで使用できます。別のBindにより、以前にバインドされた変数の値を上書きできます。

Bindオペレーションは、Var、ValueおよびPathの3つの要素で定義され、最後の要素はオプションです（空のパスと同等とみなされる）。

Varには、新しい変数に対する一意の名前が含まれています。変数の前には「?」という文字が置かれ、それは変数名の一部ではありません。

Valueは、パス式を辿る時の出発点として用いられるRDF用語です。

Pathは、変数がバインドされるRDF用語を識別するために用いられる表現です。それは、 Step（ステップ）および／またはConstraint（制約）で構成されます。

上例に従うと、Bindオペレーションにより、eventと呼ばれる新しい変数が作成され、<#>というRDF用語で始まり、この変数がバインドされるRDF用語を識別するために/ schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ]というパス式 – つまり、ターゲット・グラフ内の_:b2 – を辿ります。

例20
Bind ?event <#> / schema:performerIn [ / schema:url = <https://www.w3.org/2012/ldp/wiki/F2F5> ] .

4.3.2 Add

Addオペレーションは、ターゲット・グラフに新しいRDFトリプルを追加するために用いられます。

これは、引数グラフgという1つの引数を持ちます。gのすべてのトリプルがtarget graphに追加されなければなりません。ターゲット・グラフ内にすでに存在している1つ以上のトリプルが引数グラフに含まれていれば、Addオペレーションは失敗ではありません。

例21
Add {
    <#> profile:first_name "Timothy" ;
        profile:image <https://example.org/timbl.jpg> .
} .

Add { ?event rdf:type schema:Event } .

4.3.3 AddNew

AddNewオペレーションは、ターゲット・グラフに新しいRDFトリプルを追加するために用いられます。これはAddと似た挙動をしますが、Addとは違い、AddNewは、既存のトリプルを追加しようとすると失敗となります。

4.3.4 Delete

Deleteオペレーションは、ターゲット・グラフからRDFトリプルを削除するために用いられます。

これは、引数グラフgという1つの引数を持ちます。gのすべてのトリプルがtarget graphから削除されなければなりません。それらのトリプルのうちの1つがターゲット・グラフに存在していなければ、失敗ではありません。Deleteステートメントでは空白ノード識別子が認められていますが、LDパッチ・ドキュメントを範囲としていなければならいため、同じLDパッチ・ドキュメントによって以前に追加された空白ノードとマッチするだけかもしれません。

例22
Delete { <#> profile:first_name "Tim" } .

Delete { ?ted schema:startDate "2009-02-04" } .

4.3.5 DeleteExisting

DeleteExistingオペレーションは、ターゲット・グラフからRDFトリプルを削除するために用いられます。これはDeleteと似た挙動をしますが、Deleteと違い、DeleteExistingは、存在していないトリプルを削除しようとすると、失敗となります。

4.3.6 Cut

Cutオペレーションは、特定の空白ノードbに接続されている1つ以上のトリプルを削除するために用いられます。より正確に言えば、これはbに対するすべての外向きアークをターゲット・グラフから削除し、空白ノードであるそれらのトリプルのすべてのオブジェクトに対して再帰的に同じ動作を実行します。最終的に、bのすべての内向きアークが削除されます。

例23
Cut ?workLocation .

4.3.7 UpdateList

UpdateListオペレーションは、RDFコレクションの一部のメンバーを更新するために用いられます。これは、Pythonのスライス表記（slicing）や類似の言語と同じように機能し、リストのスライスを別のリストに置き換えます。

UpdateListオペレーションは、変数またはIRI、述語、スライス式、RDFコレクションが含まれている引数グラフという4つの要素で定義されます。

スライス式は、「..」で区切られた、オプションの2つのiminとimaxという、0から始まるインデックスで構成されています。負のインデックスは、リストの終わりから逆に数えた要素を示します（例えば、空でないリストの最後の要素のインデックスは常に-1）。省略された値は、コレクションの長さと解釈されます。スライス式は、iminという要素で始まるリストのスライスを示し、（imax - imin）の要素の範囲となります。

例えば、( "lorem" "ipsum" "dolor" "sit" "amet" )というリストに対するスライス式を以下にいくつか挙げます。

  • 2..4は、( "dolor" "sit" )というスライス、つまり、インデックス2と4の間の要素を示します。
  • 0..は、( "lorem" "ipsum" "dolor" "sit" "amet" )というスライス、つまり、全リストを示します。
  • 3..は、( "sit" "amet" )というスライス、つまり、インデックス3以後のすべての要素を示します。
  • -2..は、( "sit" "amet" )というスライス、つまり、最後の2つの要素を示します。
  • 2..2は、"ipsum"と"dolor"の間に位置する空のスライスを示します。
  • ..は、リストの終わりに位置する空のスライスを示します。

付録Aには、具象化されたrdf:Listを用いてUpdateListロジックを実装するための詳細なアルゴリズムが含まれています。

4.3.8 エラー処理

LDパッチは、次の点においてHTTP PATCHメソッド[RFC5789]のセマンティクスに従います。サーバーは、変更の集合全てをアトミックに適用しなければならず（MUST）、部分的に修正された表現を（例えば、このオペレーション中にGETに応答して） 決して提供してはなりません。全てのパッチ・ドキュメントの適用が成功しない限り（例えば、手順のうちの1つが失敗した場合は）、サーバーは、いかなる変更も適用してはなりません（MUST NOT）。LDパッチ・オペレーションの適用に失敗した場合には、使用するエラー・コードは[RFC5789]の2項、エラー処理により指定されます。

以下に、LDパッチに特化したいくつかの追加のエラー条件を挙げます。

  • Bindステートメントが、きっかり1つのノードとのマッチに失敗した場合には、HTTP 422（処理できないエンティティ）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • 単一性制約に違反している場合には、HTTP 422（処理できないエンティティ）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • Cutオペレーションが、トリプルの削除に失敗した場合には、HTTP 422（処理できないエンティティ）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • Cutオペレーションが、空白ノードにバインドされていない変数で呼び出されれば、HTTP422（処理できないエンティティ）のエラー・ステータ・スコードが返されなければなりません（MUST）。
  • DeleteExistingが、存在していないトリプルを削除しようとした場合には、HTTP 422（処理できないエンティティ）エラー・ステータス・コードが返されなければなりません（MUST）。
  • AddNewが、既存のトリプルを追加しようとした場合には、HTTP422（処理できないエンティティ）のエラー・ステータ・スコードが返されなければなりません（MUST）。
  • UpdateListに提供された主語と述語に、一意の目的語がない、または、この目的語が整形式のコレクションではない場合には、HTTP 422（処理できないエンティティ）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • ライス式のインデックスの順序が間違っている場合（例えば2868..42）には、解析は失敗し、400（不正リクエスト）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • スライス式のインデックスがrdf:Listの長さより大きい場合には、422（処理できないエンティティ）のエラー・ステータス・コードが返されなければなりません（MUST）。
  • 事前の宣言なしに接頭辞名（PNAME_NS）が用いられた場合には、解析は失敗し、400（不正リクエスト）のエラー・ステータス・コード返されなければなりません（MUST）
  • 事前にバインドされずに変数（variable）が用いられた場合には、解析は失敗し、400（不正リクエスト）のエラー・ステータス・コード返されなければなりません（MUST）。

注：422（処理できないエンティティ）は、[RFC4918]の11.2項、422 処理できないエンティティで定義されています。

4.3.9 異常なグラフ

LDパッチが対処できない特定のケースが存在しています。下記の場合に、RDFグラフGであるとき、(n, p)という対が存在していれば、空白ノードbは、Gにおいて明白だと言えます。

{n}にpを適用した結果、{b}というシングルトンの集合が生成されるような、
  • nがIRIまたはリテラルであるもの。
  • pがパス式であるもの。

容易にわかるように、LDパッチではグラフの明白な空白ノードのみを処理できます。

例えば、次のグラフを見てみましょう。

例24
<#> foaf:name "Alice" ; foaf:knows _:b1, _:b2 .
_:b1 a foaf:Person .
_:b2 a foaf:Person ; schema:workLocation _:b3 .
_:b3 schema:name "W3C/MIT" .

空白ノード_:b2と_:b3は、それらが"W3C/MIT"というリテラルから明白に到達できるため、明白です。一方で、空白ノード_:b1は、それとマッチしうるすべてのパス式が_:b2にもマッチするため、明白ではありません。

もうひとつの例は、空白ノードのみが含まれているグラフです。IRIやリテラルから到達できないため、そのすべてのノードは明白ではありません。このようなグラフは、それから、または、それにリンクするためのIRIが含まれていないため、リンクト・データの文脈においては興味深くありません。

したがって、明白ない空白ノードは、リンクト・データの文脈においては異常なケースとみなされ、したがって、LDパッチではそれらに対処できないという事実を受け入れることができると思います。さらに、グラフにそれらが存在することで、そのグラフの他のノードがLDパッチでは処理できないということはありません。特に注目すべきなのは、すべての簡潔でないグラフ[rdf11-mt]も異常だという点です。

5. TurtleおよびSPARQLとLDパッチとの比較

この項は非規範的です。

LDパッチ構文は、そのトリプル生成規則にTurtle[Turtle]形式の構文を用います。主語と目的語の生成規則において変数の使用が認められているという点で、この生成規則はTurtle言語と異なっています。

LDパッチの変数は、SPARQL 1.1[sparql11-query]のVAR1生成規則に限定されており、先頭の「?」のみが認められています。

最後に、接頭辞指示子は、Turtle[Turtle]のprefixID生成規則に限定されており、@prefixのみが認められています。

6. 具象構文

[135s]のように、番号の末尾に「s」が付いている生成規則ラベルは、SPARQL 1.1クエリ言語文法[sparql11-query]内のその番号の生成規則を参照します。[6t]のように、番号の末尾に「t」が付いている生成規則ラベルは、Turtle文法[Turtle]のその番号の生成規則を参照します。[10t*]や[12t*]のように後ろに「*」が付いている生成規則ラベルは、修正された規則を示します。

[1] ldpatch ::= prologue statement*
[2] prologue ::= prefixID*
[3] statement ::= bind | add | addNew | delete | deleteExisting | cut | updateList
[4] bind ::= ("Bind" | "B") VAR1 value path? "."
[5] add ::= ("Add" | "A") "{" graph "}" "."
[6] addNew ::= ("AddNew" | "AN") "{" graph "}" "."
[7] delete ::= ("Delete" | "D") "{" graph "}" "."
[8] deleteExisting ::= ("DeleteExisting" | "DE") "{" graph "}" "."
[9] cut ::= ("Cut" | "C") VAR1 "."
[10] updateList ::= ("UpdateList" | "UL") varOrIRI predicate slice collection "."
[11] varOrIRI ::= iri | VAR1
[12] value ::= iri | literal | VAR1
[13] path ::= ( '/' step | constraint )*
[14] step ::= '^' iri | iri | INDEX
[15] constraint ::= '[' path ( '=' value )? ']' | '!'
[16] slice ::= INDEX? '..' INDEX?
[17] INDEX ::= '-'? [0-9]+
[143s] VAR1 ::= '?' VARNAME
[166s] VARNAME ::= ( PN_CHARS_U | [0-9] ) ( PN_CHARS_U | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )*
[4t] prefixID ::= "@prefix" PNAME_NS IRIREF "."
[18] graph ::= triples ( '.' triples )* '.'?
[6t] triples ::= subject predicateObjectList | blankNodePropertyList predicateObjectList?
[7t] predicateObjectList ::= verb objectList (';' (verb objectList)?)*
[8t] objectList ::= object (',' object)*
[9t] verb ::= predicate | 'a'
[10t*] subject ::= iri | BlankNode | collection | VAR1
[11t] predicate ::= iri
[12t*] object ::= iri | BlankNode | collection | blankNodePropertyList | literal | VAR1
[13t] literal ::= RDFLiteral | NumericLiteral | BooleanLiteral
[14t] blankNodePropertyList ::= '[' predicateObjectList ']'
[15t] collection ::= '(' object* ')'
[16t] NumericLiteral ::= INTEGER | DECIMAL | DOUBLE
[128s] RDFLiteral ::= String (LANGTAG | '^^' iri)?
[133s] BooleanLiteral ::= 'true' | 'false'
[17] String ::= STRING_LITERAL_QUOTE | STRING_LITERAL_SINGLE_QUOTE | STRING_LITERAL_LONG_SINGLE_QUOTE | STRING_LITERAL_LONG_QUOTE
[135s] iri ::= IRIREF | PrefixedName
[136s] PrefixedName ::= PNAME_LN | PNAME_NS
[137s] BlankNode ::= BLANK_NODE_LABEL | ANON
[18] IRIREF ::= '<' ([^#x00-#x20<>"{}|^`\] | UCHAR)* '>' /* #x00=NULL #01-#x1F=control codes #x20=space */
[139s] PNAME_NS ::= PN_PREFIX? ':'
[140s] PNAME_LN ::= PNAME_NS PN_LOCAL
[141s] BLANK_NODE_LABEL ::= '_:' (PN_CHARS_U | [0-9]) ((PN_CHARS | '.')* PN_CHARS)?
[144s] LANGTAG ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)*
[19] INTEGER ::= [+-]? [0-9]+
[20] DECIMAL ::= [+-]? [0-9]* '.' [0-9]+
[21] DOUBLE ::= [+-]? ([0-9]+ '.' [0-9]* EXPONENT | '.' [0-9]+ EXPONENT | [0-9]+ EXPONENT)
[154s] EXPONENT ::= [eE] [+-]? [0-9]+
[22] STRING_LITERAL_QUOTE ::= '"' ([^#x22#x5C#xA#xD] | ECHAR | UCHAR)* '"' /* #x22=" #x5C=\ #xA=new line #xD=carriage return */
[23] STRING_LITERAL_SINGLE_QUOTE ::= "'" ([^#x27#x5C#xA#xD] | ECHAR | UCHAR)* "'" /* #x27=' #x5C=\ #xA=new line #xD=carriage return */
[24] STRING_LITERAL_LONG_SINGLE_QUOTE ::= "'''" (("'" | "''")? ([^'\] | ECHAR | UCHAR))* "'''"
[25] STRING_LITERAL_LONG_QUOTE ::= '"""' (('"' | '""')? ([^"\] | ECHAR | UCHAR))* '"""'
[26] UCHAR ::= '\\u' HEX HEX HEX HEX | '\\U' HEX HEX HEX HEX HEX HEX HEX HEX
[159s] ECHAR ::= '\' [tbnrf"'\]
[161s] WS ::= #x20 | #x9 | #xD | #xA
[162s] ANON ::= '[' WS* ']'
[163s] PN_CHARS_BASE ::= [A-Z] | [a-z] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x02FF] | [#x0370-#x037D] | [#x037F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[164s] PN_CHARS_U ::= PN_CHARS_BASE | '_'
[166s] PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040]
[167s] PN_PREFIX ::= PN_CHARS_BASE ((PN_CHARS | '.')* PN_CHARS)?
[168s] PN_LOCAL ::= (PN_CHARS_U | ':' | [0-9] | PLX) ((PN_CHARS | '.' | ':' | PLX)* (PN_CHARS | ':' | PLX))?
[169s] PLX ::= PERCENT | PN_LOCAL_ESC
[170s] PERCENT ::= '%' HEX HEX
[171s] HEX ::= [0-9] | [A-F] | [a-f]
[172s] PN_LOCAL_ESC ::= '\' ('_' | '~' | '.' | '-' | '!' | '$' | '&' | "'" | '(' | ')' | '*' | '+' | ',' | ';' | '=' | '/' | '?' | '#' | '@' | '%')

A. UpdateListアルゴリズム

この項は非規範的です。

下記は、具象化された（つまり、rdf:firstとrdf:restでエンコードされた）rdf:Listが存在するときにUpdateList s p imin..imax collectionをどのように処理できるかを説明しているアルゴリズムです。実装者は、rdf:Listに対してよりネイティブなエンコーディングを利用できます。

以前のアルゴリズムの説明は次のとおりです。

図1 コレクションのグラフで表されているグラフを見てみましょう。そのグラフのコレクションにオペレーションUpdateList :s :p 2..4 ("foo" "bar" "baz") .を適用した結果は、図2 UpdateListの適用で見ることができます。

( &quote;lorem&quote; &quote;ipsum&quote; &quote;dolor&quote; &quote;sit&quote; &quote;amet&quote; ) ( &quote;foo&quote; &quote;bar&quote; &quote;baz&quote; )
図1 コレクションのグラフ
( &quote;lorem&quote; &quote;ipsum&quote; &quote;dolor&quote; &quote;sit&quote; &quote;amet&quote; ) ( &quote;foo&quote; &quote;bar&quote; &quote;baz&quote; )
図2 UpdateListの適用

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

連絡先:
Andrei Vlad Sambra
参照:
W3C仕様に関するメディア・タイプの登録方法
インターネット・メディア・タイプ登録、使用の整合性
TAGの発見事項 2002年6月3日（2002年9月4日改定）

LDパッチのインターネット・メディア・タイプ/MIMEタイプは、「text/ldpatch」です。

Pending discussion/registration with IETF.

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

Possible namespace conflict for .ldp!

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

タイプ名:
text
サブタイプ名:
ldpatch
必須パラメータ:
なし
任意のパラメータ:
charset — このパラメータは、非ASCIIデータを転送する際に必要です。charsetは、それがもしあれば、常にUTF-8[UTF-8]です。
コード化に関する留意点:
LDパッチの構文は、Unicode[UNICODE]のコード・ポイントで表されます。コード化は、常にUTF-8[UTF-8]です。Unicodeコード・ポイントは、Xが16進の[0-9A-Fa-f]である場合、\uXXXX（U+0～U+FFFF）または\UXXXXXXXX構文（U+10000以降）を用いて表現できます。
セキュリティに関する留意点:
Turtleとの関係により、ここでも同じセキュリティに関する留意点を適用できます。アプリケーションは、より多くの言明を推論したり、IRIを逆参照するためにデータを評価でき、そのIRIのスキームに関するセキュリティ上の検討事項が生じます。特に、HTTP IRIに関する[RFC3023]の10項のプライバシー問題に注意してください。不正確または悪質なデータ情報源から得たデータは、意図しないIRIの逆参照のみならず、不正確または誤解を招く結果に結びつくかもしれません。調べた資源に対する信頼性を、意図されているデータ利用の感度と慎重に合わせなければなりません。例えば、潜在的な内科療法の推論には、旅行計画の推論とは恐らく異なる信頼性が必要でしょう。信頼できないLDパッチ情報源から検索された文字列を表示するアプリケーションは、読者を誤解させるような悪質な文字列が用いられていなことを保証しなければなりません。XMLのメディア・タイプ登録におけるセキュリティに関する留意点（[RFC3023]の10項）は、任意のデータとマークアップの表現に関するガイダンスを追加提供します。 LDパッチは、IRIを用語識別子として用います。LDパッチで表現されたデータを解釈するアプリケーションは、URI（Uniform Resource Identifier）: 一般的構文[RFC3986]の7項とIRI（Internationalized Resource Identifiers）[RFC3987]の8項のセキュリティ問題に取り組むべきです。複数のIRIの見た目が同じでありえます。異なるスクリプトの文字が同じに見えるかもしれません（キリル文字の「о」はラテン文字の「o」と同じに見えるかもしれません）。結合文字が後続する文字は、別の文字と同じ視覚的表現を持っているかもしれません（結合アキュート・アクセントが後続するラテン小文字Eは、アキュート付きラテン小文字Eと同じ視覚的表現を持っています）LDパッチのデータを記述または解釈する人やアプリケーションは、意図するセマンティクスとマッチするIRIを慎重に用いて、同じように見えるIRIを回避しなければなりません。類似している文字のマッチングに関する詳細は、Unicodeセキュリティに関する留意点[UNICODE-SECURITY]およびIRI（Internationalized Resource Identifiers）[RFC3987]の8項にあります。
互換性に関する留意点:
互換性の問題は知られていません。
公開済み仕様書:
この仕様書。
このメディア・タイプを使用するアプリケーション:
このメディア・タイプを用いる広く展開したアプリケーションは知られていません。これは、これらのデータを用いる一部のウェブ・サービスとクライアントで使用できます。
追加情報:
マジック・ナンバー:
LDパッチのドキュメントは、ドキュメントの冒頭近くに文字列「@prefix」（大文字・小文字を区別する）を持つことができます。
ファイル拡張子:
「.ldp」
マッキントッシュ・ファイル・タイプ・コード::
「TEXT」
詳細情報に関する連絡先:
Andrei Vlad Sambra <andrei@w3.org>
意図する使途:
汎用
使用上の制限:
なし
著者／改版管理者:
W3Cは、この仕様書に対する変更管理を保持します。

C. 謝辞

この項は非規範的です。

この仕様の作成において、次の方々（アルファベット順）に、アイデア、フィードバック、レビュー、コンテンツ、批評およびインプットの提供でご協力いただきました。

Andy Seaborne、Arnaud Le Hors、Ashok Malhotra、Eric Prud'hommeaux、Henry Story、John Arwe、Sandro Hawke、Steve Speicher、Tim Berners-Lee

D. 変更履歴

この項は非規範的です。

D.1 2015年3月の勧告候補以後の変更

D.2 2014年9月の最初の草案以後の変更

E. 参考文献

E.1 規範的な参考文献

[BCP47]
A. Phillips; M. Davis. Tags for Identifying Languages. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. W3C Recommendation. URL: http://www.w3.org/TR/ldp/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3023]
M. Murata; S. St. Laurent; D. Kohn. XML Media Types. January 2001. Proposed Standard. URL: https://tools.ietf.org/html/rfc3023
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC3987]
M. Duerst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[RFC4918]
L. Dusseault, Ed.. HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). June 2007. Proposed Standard. URL: https://tools.ietf.org/html/rfc4918
[RFC5789]
L. Dusseault; J. Snell. PATCH Method for HTTP. March 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5789
[Turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/
[UNICODE]
The Unicode Standard. URL: http://www.unicode.org/versions/latest/
[UNICODE-SECURITY]
Mark Davis; Michel Suignard. Unicode Security Considerations. URL: http://www.unicode.org/reports/tr36/
[UTF-8]
F. Yergeau. UTF-8, a transformation format of ISO 10646. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629
[rdf11-concepts]
Richard Cyganiak; David Wood; Markus Lanthaler. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf11-concepts/
[rdf11-mt]
Patrick Hayes; Peter Patel-Schneider. RDF 1.1 Semantics. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf11-mt/
[sparql11-query]
Steven Harris; Andy Seaborne. SPARQL 1.1 Query Language. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-query/

E.2 参考情報の参考文献

[sparql11-update]
Paul Gearon; Alexandre Passant; Axel Polleres. SPARQL 1.1 Update. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-update/