要約

この入門は、リンクト・データ・プラットフォーム（LDP）への手引きとなるものです。例を用いて、LDP資源の概念、LDPコンテナ、それらをWebクライアントで使用できる方法などの主な概念を説明しています。2つのシナリオの例は、読み書き用リンクト・データ・アプリケーションの文脈において、どのようにLDPクライアントがLDPサーバーと相互作用できるか、つまり、資源をリンクト・データとして提供するサーバーの資源に、HTTPを用いてアクセス、更新、作成、削除する方法を示しています。

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

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

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

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

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

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

目次

1. はじめに

「リンクト・データ」[LINKED-DATA]という用語は、リンク付けをデータ概念の中心に置き、グローバルな分散型データベースの作成を可能とするためにウェブが提供するリンク付け技術を用いるデータ公開のアプローチを意味します。現実の世界のエンティティに - ウェブ資源であるか、エッフェル塔などの物体であるか、関係や概念などのより多くの抽象的な事物であるかを問わず - http(s) URLで名前を付与し（そのURLでドキュメントを逆参照することにより、意味を決定できる）、RDFが提供する関係のフレームワークを用いることにより、ウェブ・ページと同じ方法でデータを公開しリンクできます。リンクト・データ・プロトコルは、HTTPプロトコルを用いて、ウェブ・アプリケーションが、資源を発見し、リンクをたどり、新しい資源を公開し、既存の資源を編集・削除できる方法を規定します。

この入門は、ベスト・プラクティス[LDP-BP]に従い、LDPプロトコル利用に関する初歩的な例と手引きを提供することを目指します。プロトコルの体系的な記述に関しては、規範的なLDP参考文献[LDP]を参照すべきです。LDPのユースケースとその設計を導いた要件の概要に関しては、LDPユースケースおよび要件[LDP-UCR]を、ベスト・プラクティスとガイドラインに関しては、LDPのベスト・プラクティスおよびガイドラインのドキュメント[LDP-BP]を参照すべきです。

このドキュメントで用いる慣習

このガイドの例は、RDFのTurtle[turtle]とJSON-LD[json-ld]構文を用いたRDFグラフのシリアル化として示します。

下のボタンで、利用可能な構文を表示または隠すことができます。

LDP概念の概観

リンクト・データ・プラットフォーム資源（LDPRs）を提供するサーバーは、RDFを用いて状態を表す資源（LDP RDF情報源（LDP-RSs）と呼ばれる）と、HTMLファイル、画像、その他のバイナリ・ファイルなどのその他のフォーマット（LDP非RDF情報源（LDP-NRs）と呼ばれる）の2種類のLDPRsを管理できます。資源は、HTTP GETを用いた検索オペレーションに応答します。レスポンス・ドキュメントで伝えられる内容は、しばしば、ステータス（Status）、友好関係（Friendship）、製品（Product）、注文（Order）、バグ（Bug）などの特定領域のエンティティを表します。一方で、それには多くの様々な概念の記述が含まれているかもしれません。記述に含まれているリンクは、以後の発見と他の資源の処理につながります。サーバーが提供するアフォーダンスにより、アプリケーション内のフォワード・パスを発見できます。資源、リンクおよび関連するアフォーダンスを合わせると、APIと呼べるものが規定されます。

LDPRsの種類: LDPRsの種類

LDPプロトコルは、資源との読み書きの相互作用をカバーします。書き込み可能な側面には、新しい資源の作成（POSTまたはPUTを用いる）、更新（PUTまたはPATCHを用いる）、資源の削除が含まれます。資源の作成は、構造化された資源の作成を提供する必須の機能です。サーバーが公開するアフォーダンスは、他の資源を作成するために一部の資源を使用できることを表します。ドキュメントで構成されるドキュメント・ストア、バグ・レポートで構成されるバグ追跡システム、写真で構成されるフォト・アルバム、人の財産と債務で構成される人の自己資本など、1つの資源が他の多くの資源で構成される場合に、しばしばこの共通のパターンが見られます。LDPは、コンテナと呼ばれる特殊な資源（LDPC）の作成を定義し、これは、HTTPが定義している一般メカニズムに加えて、リクエストに応答して新しい資源を作成することができます。作成中に、作成された資源がそのコンテナに追加され、コンテナと新しいエントリーの間の包含リンクが作成されます。

したがって、LDPCは、LDPRsに対するリンクのコレクション（集合）を表すLDP-RSを特殊化したもの、または、作成、変更および／またはリンク付けされたメンバーやドキュメントの列挙に関するクライアントのリクエストに応答する情報資源[WEBARCH]です。最もシンプルなコンテナは、基本コンテナ（LDP-BC）です。それは、一般的な語彙で記述された基本的な包含を定義します。これは、任意の資源の包含階層を管理するために、一般的なストレージ・サービスで使用できます。

..
図1 基本コンテナを用いた一般的な文書ストレージ

このようなサーバーは、LDPRsに制限を課さず、一般的に、領域固有のアプリケーション・ロジックや語彙がなくてもストレージ・システムとして機能します。このドキュメントの最初のシナリオは、基本コンテナに基づいたドキュメント・ストレージ・システムに関するものです。

直接コンテナは基本コンテナを特殊化したものです。領域固有の語彙を用いる、メンバーシップ・トリプルと呼ばれる追加の言明が、作成工程の一環として直接コンテナにより作られます。メンバーシップ・トリプルは、すべてのコンテナにより維持されている包含トリプルを増強します。例えば、製品在庫システムの一側面は、どのように直接コンテナを製品群の管理に用いるかに関係しており、その場合、既存の語彙を用いることが望ましいです。

..
図2 直接コンテナで領域の語彙を使用

直接コンテナのメンバーシップ・トリプルは、コンテナ資源以外の主題に関するものでありえます。その例の1つは、写真管理のために写真コンテナを用いる写真管理アプリケーションで、その時のメンバーシップ・トリプルはユーザと写真との関係を表します。

..
図3 非コンテナの主語を持つメンバーシップ・トリプル

別の一般的なパターンは、複数のコンテナを用いて異なるファセットの資源が管理されているケースです。例えば、バグ・レポートには、サポートしているメディア資源のみでなく、関連するコメントのリストが含まれています。

..
図4 2つの直接コンテナでバグの複数ファセットを管理

1つの重要な使用方法は、既存アプリケーションのデータとサービスを提供するためにLDPを用いるケースに関するものです。LDPの相互作用では、潜在的なビジネス・ロジックとデータ・モデルの制約に配慮すべきであるため、このシステムはLDPRsに制限を課します。この入門の後半で示しているバグ追跡システムの例は、アプリケーション固有のLDPサーバーの例です。

注

LDPR、LDPCという用語やLDPで導入されたその他の概念の形式的な定義は、リンクト・データ・プラットフォーム1.0仕様[LDP]の「用語」の項にあります。

リンクト・データ・プラットフォームの相互作用を示すために、以下に一連の例を提供します。これは入門であり、理想的なLDPモデリングの規範的な例であると考えるべきではないことに注意してください。

2. オンライン・ドキュメント・ストアの例（LDP基本）

この項では、オンライン・ドキュメント・ストアのアプリケーションを用いた例を提供します。これらの例は、LDPRsとLDP基本コンテナの両方の形式の挙動を示します。オンライン・ドキュメント・ストアのアプリケーションを用いてユーザ登録を行った結果として、アプリケーションのウェブ資源を蓄積するデータ・ストレージ空間（ルート基本コンテナ）が生成されます。ユーザは、このルート基本コンテナを用いて、新しいドキュメント作成し、さらに子コンテナも作成したうえで、自身のドキュメントを構築してこのアプリケーションに蓄積できます。

一般的に、ウェブ・アプリケーションのAPIは、URLで動作可能な有効なオペレーションを列挙することでドキュメント化され、その場合、URLがテンプレートとして記述されます。模範的なLDPベースのドキュメント・ストアの記述は、以下の表にあります。サーバーが、資源の位置を明らかにするための主要なメカニズムとしてリンクを用いるということが重要であることに特に注意してください。このテンプレートをクライアント・アプリケーションにエンコードする必要がある場合は、それは、その設計が多くの優れた設計原則に反するものであることを強く示しています。

パス メソッド 説明
/{username}/ GET ルート・コンテナの全ドキュメントを列挙する。
POST ルート・コンテナ下に新しいドキュメントを作成する。
PUT ルート・コンテナのファイルの記述および／またはリストを更新する。
PATCH ルート・コンテナのファイルの記述および／またはリストを更新する。
DELETE 認められていない。
/{username}/{{document}/}*
 GET ドキュメントを検索する。
POST 資源のアフォーダンスから発見される。
PUT ドキュメントを更新する。
PATCH PATCHがサポートされていれば、ドキュメントに対する部分的な更新を行う。
DELETE ドキュメントを削除する。
/*/*
 OPTIONS 資源に認められているオペレーションを発見する。
HEAD 資源に関するメタ情報のみを検索する。

この例では、アリス（このシステムのユーザ）がLDPプロトコルを用いてドキュメントの管理情報を読む／書き込む方法を見ます。典型的なシステムとの相互作用は、アリスをユーザとして登録するところから始まります。登録はLDPベースの相互作用である可能性が高いですが、この側面はこの例の範囲外です。登録の結果は、ドキュメントのストレージに対する空間の割り当てと、ユーザに対するこのURLの通知です（例えば、http://example.org/alice/における基本コンテナ）。この項では、アリスが最初にルート・ドキュメントを読み、そのアフォーダンスを発見するという典型的な相互作用の流れを説明しています。これは、その後の作成、更新、削除の例へと続き、どのようにクライアントがコンテナから入れ子の構造を作成できるかで終わります。

2.1 基本コンテナの検索（LDP-BCに対するGET）

最初に、アリスは、ドキュメントの保持用に彼女に割り当てられたLDP基本コンテナを検索することで、自分のストレージを探します。アリスのLDPクライアントは、http://example.org/alice/というURIに対するGETリクエストによりこれを行います。

例1: リクエスト - 基本コンテナ検索
Turtle:
GET /alice/ HTTP/1.1
Host: example.org
Accept: text/turtle

彼女のドキュメント・ストレージは、作成されたばかりなので、空のコンテナです。

例2: レスポンス - 基本コンテナ検索
Turtle:
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json, image/bmp, image/jpeg
Accept-Patch: text/ldpatch
Content-Length: 250
ETag: W/'123456789'
	
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
	
<http://example.org/alice/> a ldp:Container, ldp:BasicContainer;
  dcterms:title 'Alice’s data storage on the Web' .

例で示しているように、リクエストされたメディア・タイプを用いた基本コンテナのRDF表現に加え、サーバーは、資源表現のETagと、リクエストされた資源が実際にはLDP基本コンテナであり、それがLDPの相互作用モデルをサポートしていることを公言するLinkヘッダーを提供します。

さらに、レスポンスには、「Allow」、「Accept-Post」、「Accept-Patch」のヘッダーも含まれています。「Allow」ヘッダーは、このLDP基本コンテナ資源がどのHTTPオペレーションをサポートしているかを公言します。この例では、OPTIONS、HEAD、GET、POST、PUT、PATCH HTTPという動詞をサポートしています。「Accept-Post」と「Accept-Patch」のヘッダーはそれぞれ、どれがPOSTとPATCHメソッドでサポートされているメディア・タイプであるかを公言します。

注

リンクト・データ・プラットフォーム1.0仕様[LDP]では、すべてのLDPサーバーは、LDP-RS資源に対してTurtleメディア・タイプをサポートしなければならず（MUST）、JSON-LDメディア・タイプをサポートすべきである（SHOULD）と記述されています。

2.2 アフォーダンスの発見（LDP-BCに対するOPTIONS）

前の例で、資源にGETリクエストを行うことで、資源にどのようなオペレーションが認められているかをアリスが発見できることが分かりました。別の方法として、彼女は、任意の資源に認めらているオペレーションを知るために、OPTIONSオペレーションを用いることもできます。

例3: リクエスト - 基本コンテナのOPTIONS検索
OPTIONS /alice/ HTTP/1.1
Host: example.org
例4: リクエスト - 基本コンテナのOPTIONS検索
HTTP/1.1 204 No Content
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json, image/bmp, image/jpeg
Accept-Patch: text/ldpatch
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type"

レスポンスによると、彼女のルート・コンテナでは、{OPTIONS、HEAD、GET、POST、PUT、PATCH}というHTTPオペレーションが認められています。認められているオペレーションに加えて、Accept-PostとAccept-Patchにより、それぞれのオペレーションにどのメディア・タイプがサポートされているかが分かります。rel="type"というLinkヘッダーは、この資源はLDPプロトコルをサポートしており、それはLDP基本コンテナであると公言します。

このケースでは、レスポンスは、これがLDP基本コンテナであり、そのコンテナではRDFタイプ（text/turtle、application/ld+json）と画像（image/bmpとimage/jpeg）の両方の事物に対してPOSTが認められていることをアリスのLDPクライアントに伝えています。

2.3 コンテナと構造的階層の作成

ドキュメント・ストアは、クライアントがドキュメントの管理に階層を導入できるようにコンテナ資源の作成を許可し、それによって、アリスが自分のドキュメントを組織化するためにコンテナ階層を作成できるようになります。これは、（子）コンテナ表現を（親）コンテナにPOSTすることによって行うことができます。例えば、それにより、アリスは、画像ストレージとしての利用を想定して子コンテナを作成することができます。

..
図5 基本コンテナ内の子コンテナ
例5: 写真の（子）コンテナを作成する前のアリスのドキュメント・ストアの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.org/alice/> a ldp:Container, ldp:BasicContainer ;
    dcterms:title "Alice’s data storage on the Web" ;
    ldp:contains <http://example.org/alice/foaf> .

写真の管理用に新しいコンテナを作成するために、アリスは、コンテナの表現（LDP-BC）をルート・コンテナにPOSTします。アリスは、「type」という関係を用いてリクエスト内にLinkヘッダーを含めることで、新しく作成された資源はLDP基本コンテナであるべきだという意図を表します。

例6: リクエスト - 新しいコンテナの作成
Turtle:
POST alice/ HTTP/1.1
Host: example.org
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp/BasicContainer>; rel="type"
Slug: photos

@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
 
<> a ldp:Container, ldp:BasicContainer;
   dcterms:title "Photos of Alice" ; 
   dcterms:description "This container will contain photos of Alice." .

POSTが成功すれば、サーバーは、写真に対して新しく作成されたコンテナの位置で応答します。

例7: レスポンス - 新しいコンテナの作成
HTTP/1.1 201 Created
Location: http://example.org/alice/photos/
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0

これは、新しいコンテナを作成した後の親コンテナがどのようなものかを表しています。

例8: 写真の（子）コンテナを作成した後のアリスのドキュメント・ストアの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.org/alice/> a ldp:Container, ldp:BasicContainer ;
    dcterms:title "Alice’s data storage on the Web";
    ldp:contains <http://example.org/alice/foaf> , <http://example.org/alice/photos/> .

そして、写真のコンテナは次のようになります。

例9: アリスの新しく作成された写真コンテナの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.org/alice/photos/> a ldp:Container, ldp:BasicContainer;
  dcterms:title "Photos of Alice" ;
  dcterms:description "This container will contain photos of Alice." .

2.4 RDF資源の作成（LDP-BCに対するRDF資源のPOST）

アリスは、自分のドキュメント・ストアのルートでFOAFの個人プロフィール・ドキュメントをLDP-BCにPOSTすることにより、自分のストアに社会的なプロフィール・ドキュメントをアップロードできます。Slugヘッダーは、作成される資源のURLに関するヒントをサーバーに提供することに注意してください。アリスは、「type」という関係を用いてリクエスト内にLinkヘッダーを含めることで、新しく作成された資源はLDP資源であるべきだということも示します。

FOAFドキュメントには、作成される資源に関するステートメントと、作成される資源と関連のある他の資源が含まれています。LDP仕様に従い、作成される資源の参照用に、アリスは、リクエスト・エンティティ本文で空の相対URI (<>)を使用できます。

例10: リクエスト - RDF資源の作成
Turtle:
POST /alice/ HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Slug: foaf
Content-Type: text/turtle

@prefix dc: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
    foaf:primaryTopic <#me> ;
    dc:title 'Alice’s FOAF file' .

<#me> a foaf:Person;
    foaf:name 'Alice Smith'  .
例11: レスポンス - RDF資源の作成
HTTP/1.1 201 Created
Location: http://example.org/alice/foaf
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0

作成リクエストに対するレスポンスは、Locationヘッダーで、新しく作成された資源に対するリンク（Link）を提供します。このケースでは、サーバーは、Slugヘッダーから提供されたヒントを尊重し、http://example.org/alice/foafというURLで新しい資源を作成しました。

新しく作成された資源のURLが分かったため、アリスは、新しく作成された資源がコンテナに正しく含まれていることを確認するために、コンテナを再確認できます。

例12: リクエスト - 資源が作成された後の基本コンテナ検索
GET /alice/ HTTP/1.1
Host: example.org
Accept: text/turtle, application/ld+json
例13: レスポンス - 資源が作成された後の基本コンテナ検索
Turtle:
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json, image/bmp, image/jpeg
Accept-Patch: text/ldpatch
Content- Length: 245
ETag: W/'123456789'
  
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
  
<http://example.org/alice/> a ldp:Container, ldp:BasicContainer;
   dcterms:title 'Alice’s data storage on the Web' ;
   ldp:contains <http://example.org/alice/foaf> .

2.5 非RDF（バイナリ）資源の作成（LDP-BCに対する画像のPOST）

次に、アリスは自分の写真をドキュメント・ストレージにアップロードしたいと考えます。RDFドキュメントを作成したのと同じ方法でPOSTを行うことで画像を作成できます。

例14: リクエスト - 非RDF資源の作成
POST /alice/ HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Slug: avatar
Content-Type: image/png
Content- Length: 1020

### binary data ###
例15: レスポンス - 非RDF資源の作成
HTTP/1.1 201 Created
Location: http://example.org/alice/avatar
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://example.org/alice/avatar/meta>; rel="describedby"
Content-Length: 0

非RDFを作成した結果は、RDF資源の作成と似ています。成功すれば、サーバーは、作成された資源を指し示すLocationヘッダーと共に201の成功コードを返します。さらに、バイナリ資源の場合、サーバーは、バイナリ・ファイルに関するメタデータを維持するためのファイルを追加作成できます。上の例では、サーバーは、作成日、所有者、などのバイナリ資源に関するメタデータを維持するために新しいLDP-RSを作成し、そのメタデータ資源は、「describedby」という関係のLinkヘッダーを用いて公言されます。

RDF資源（LDP-RS）の作成と同じように、非RDF（LDP-NR）の作成時に、包含トリプルがコンテナに追加されます。したがって、画像を作成した後のLDPコンテナの表現は、次のようになります。

例16: 非RDF資源を作成した後のコンテナ表現
Turtle:
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
  
<http://example.org/alice/> a ldp:Container, ldp:BasicContainer;
   dcterms:title 'Alice’s data storage on the Web' ;
   ldp:contains <http://example.org/alice/foaf> , <http://example.org/alice/avatar> .

2.6 RDF LDP資源の更新（LDP-RSに対するPUT）

前の例で示したとおりに画像を作成した後で、アリスは画像に対するリンクで自分のFOAFプロフィールを更新したいと考えるようになりました。彼女は、HTTP GETオペレーションでFOAFプロフィールを検索した後に、HTTP PUTを用いて、写真へのリンクでRDFを修正してドキュメントを更新します。

この例では、アリスのLDPクライアントは、失われた更新（lost update）問題を防止するためにあらかじめ検索したという資源表現のE-tagを送ります。

例17: リクエスト - RDF資源の更新
Turtle:
PUT /alice/foaf HTTP/1.1
Host: example.org
If-Match: W/"123454321"
Content-Type: text/turtle

@prefix dc: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a foaf:PersonalProfileDocument;
    foaf:primaryTopic <#me> ;
    dc:title "Alice’s FOAF file" .

<#me> a foaf:Person;
    foaf:name "Alice Smith"  ;
    foaf:img <http://example.org/alice/avatar> .
例18: レスポンス - RDF資源の更新
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"

上記のとおりにオペレーションが成功すれば、ドキュメントは新しい情報により更新されます。

注

アリスは、PATCHオペレーションを用いて資源を更新することもできます。

2.7 資源の削除（LDPRに対するDELETE）

アリスが画像を削除することにした場合、彼女は削除（delete）オペレーションでそれを行えます。

例19: リクエスト - RDF資源の削除
DELETE /alice/avatar HTTP/1.1
Host: example.org
例20: レスポンス - RDF資源の削除
HTTP/1.1 204 No Content
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"

サーバーは、資源を削除するだけでなく、コンテナから包含トリプルを削除します。例えば、後でコンテナにGETリクエストを行えば、以下の表現で示しているものと同型のグラフを返します。

例21: 資源を削除した後のコンテナ表現
Turtle:
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
  
<http://example.org/alice/> a ldp:Container, ldp:BasicContainer;
   dcterms:title 'Alice’s data storage on the Web' ;
   ldp:contains <http://example.org/alice/foaf> .

削除された資源に対する事後のリクエストに対し、サーバーは適切なHTTPレスポンス・コードで応答するでしょう。

例22: リクエスト - 削除後
GET /alice/avatar HTTP/1.1
Host: example.org
Accept: image/png
例23: レスポンス - 削除後
HTTP/1.1 410 Gone

3. バグ追跡システムの例（LDP直接コンテナ）

前項では、LDP基本コンテナを用いた基本的なLDP相互作用の実例を提供しました。LDP基本コンテナの制限の1つは、コンテナとその含まれている資源の間の関係を言明するために、固定されたLDP語彙を用いることです。しかし、シナリオによっては、コンテナのメンバーを列挙するために領域固有の語彙を用いる必要があります。例えば、リンクト・データとその固有の語彙を既に用いているアプリケーションは、LDPプロトコルに移行しても同じ語彙を使い続けたいと思うかもしれません。LDP直接コンテナは、メンバーシップ・トリプルの概念を導入し、メンバーシップの形式を柔軟に定義可能とします。これらの柔軟性のポイントの1つは、領域固有の語彙からのものでありえるメンバーシップ・トリプルの述語を選択する性能です。これは、直接コンテナのldp:hasMemberRelationまたはldp:isMemberOfRelationの述語を用いて行われます。

さらに、シナリオによっては、新しく作成された資源とその他の資源の間の関係を追加することが必要です（必ずしもコンテナまたは別のドキュメントや情報資源である必要はない）。LDP直接コンテナでは、直接コンテナのldp:membershipResource述語を用いて、メンバーシップに一貫性のある主語、または、メンバーシップ・トリプルの目的語のURIを定義することで、コンテナと任意の他の情報資源または非情報資源（現実の世界の事物）の間の関係を定義できるようになります。ldp:membershipResourceとldp:hasMemberRelationの述語の用法については、以下の例で説明しています。

注

情報資源（ドキュメント）と現実の世界のエンティティ（事物）の区別の詳細に関しては、ウェブ・アーキテクチャ（2.2項 URIと資源の関係）、クールなURI（3項 実世界のオブジェクトに対するURI）、データのURL（3項 ランディング・ページとレコード）を参照してください。

この項の例は、非常にシンプルなバグ追跡システムのアプリケーションを中心に展開します。バグ追跡システムのアプリケーションは、いくつかの製品のバグを記録し、バグと製品の報告、更新、削除を可能にします。オンライン・ドキュメント・ストアの例とは異なり、バグ追跡システムには、コンテナのメンバーシップ関係を表現するために、既存の領域語彙（例えば、has_bug）の使用が必要です。LDPは、LDP直接コンテナで定義されたプロパティに基づいて領域固有のトリプルを追加するために、プロトコルに相互作用性能を追加しています。

シンプルなバグ追跡システムのRESTfulなAPIは、次のように記述できます。

パス メソッド 説明
/tracker/{product-id}/
 GET 製品に関連する製品説明とバグ・レポートを列挙する。
POST 製品に関連する新しいバグ・レポートを作成する。
PUT プロジェクトの説明を更新する。
PATCH サポートされていない。
DELETE プロジェクトの説明と関連するバグ・レポートを削除する。
/tracker/{product-id}/{bug-id}
 GET バグ・レポートを入手する。
POST サポートされていない。
PUT バグ・レポートを更新する。
PATCH サポートされていない。
DELETE バグ・レポートを削除する。
/tracker/*/*
 OPTIONS 資源に対して認められているオペレーションを発見する。
HEAD 資源に関するメタ情報のみを検索する。

この項の例では、コンテナ表現、資源の作成、削除にのみ注目します。なぜなら、それが基本コンテナ、直接コンテナ、間接コンテナで異なる部分だからです。資源の更新などのその他のオペレーションは、前の例で説明したものと同じです。

3.2 作成（LDP-DCに対する資源のPOST）

前の例に引き続き、バグ・レポートのRDF表現を製品説明に関連するLDPCにPOSTすることにより、「LDP Demo」製品説明LDPC下にバグ・レポート（バグを表すLDPR）を作成することで、「LDP Demo」製品に対するバグを報告できます。

バグ・レポート・ドキュメントには、作成される資源に関するステートメントが含まれます。LDP仕様に従って、クライアントは、作成される資源を参照するために、リクエスト・エンティティ本文に空の相対URI（<>）を使用できます。

例26: バグを作成するためのリクエスト
Turtle:
POST /tracker/ldp-demo/ HTTP/1.1
Host: example.org
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .
 
<> a bt:BugReport;
  dcterms:title "LDP Demo crashes when shutting down.";
  dcterms:creator <http://example.org/tracker/users/johndoe> .

作成が成功すれば、サーバーは、新しく作成された資源の位置で応答します。

例27: 新しいバグ作成のレスポンス
HTTP/1.1 201 Created
Location: http://example.org/tracker/ldp-demo/bug67
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0

作成が失敗すれば、サーバーは、エラーに応じた適切なステータス・コードで応答します。成功すれば、LDP Demo製品説明LDPCは、新しい資源を作成した後に、次の表現となります。

例28: バグ作成の後の製品LDPCの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .

</tracker/ldp-demo/> a ldp:DirectContainer;
  ldp:membershipResource </tracker/ldp-demo/#it>;
  ldp:hasMemberRelation bt:hasBug;
  dcterms:title "Product description of LDP Demo product which is also an LDP-DC";
  ldp:contains <bug3>, <bug4> , <bug67> .
  
</tracker/ldp-demo/#it> a bt:Product;
  dcterms:title "LDP Demo";
  bt:hasbug <bug3>, <bug4>, <bug67> .

ご覧のとおり、2つの新しいトリプルがコンテナに追加されました。それは（</tracker/ldp-demo/>, <ldp:contains>, </tracker/ldp-demo/bug67>）と（</tracker/ldp-demo/#it>, <bt:hasbug>, </tracker/ldp-demo/bug67>）です。前者はあらゆる種類のコンテナに追加され、後者は直接コンテナ・プロパティにより定義されます。

作成されたバグ資源の表現は次のようになります。POSTされたものに加えて、サーバー管理プロパティー、作成日（dcterms:created）、状態（bt:isInState）のデフォルト値をサーバーがバグに追加したことに注意してください。

例29: バグLDPRの状態
Turtle:
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .

</tracker/ldp-demo/bug67> a bt:Bug;
  dcterms:title "Product A crashes when shutting down.";
  dcterms:creator </tracker/users/johndoe>;
  dcterms:created "2013-05-05T10:00"^^xsd:dateTime;
  bt:isInState "New" .

3.3 削除（LDP-DCと関連するLDPRに対するDELETE）

この例では、資源が削除された時の直接コンテナの挙動について説明します。
例30
DELETE /tracker/ldp-demo/bug3 HTTP/1.1 
Host: example.org
If-Match: W/"123454322"

削除が成功すれば、サーバーは成功ステータス・コードで応答します。

例31
HTTP/1.1 204 No Content
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"

削除後、コンテナの表現は次のようになります。

例32: バグ削除後の製品LDPCの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .

</tracker/ldp-demo/> a ldp:DirectContainer;
  ldp:membershipResource </tracker/ldp-demo/#it>;
  ldp:hasMemberRelation bt:hasBug;
  dcterms:title "Product description of LDP Demo product which is also an LDP-DC";
  ldp:contains <bug4> , <bug67> .
  
</tracker/ldp-demo/#it> a bt:Product;
  dcterms:title "LDP Demo";
  bt:hasBug <bug4>, <bug67> .

上記のLDP直接コンテナ表現から分かるように、包含トリプル（</tracker/ldp-demo/>, ldp:contains, </tracker/ldp-demo/bug3>>と、メンバーシップ・トリプル（</tracker/ldp-demo/#it>, bt:hasBug, </tracker/ldp-demo/bug3>）の両方がコンテナ表現から削除されました。

4. 拡張バグ追跡システムの例（LDP間接コンテナ）

次の例では、前の例と同じシナリオを用いますが、LDP直接コンテナと間接コンテナの違いと、LDP間接コンテナを用いるタイミングを示すために、コンテナ型をLDP間接コンテナに変更します。LDP直接コンテナは、一貫性のあるメンバーシップURI（ldp:hasMemberRelationを用いるときにはメンバーシップ・トリプルの主語で、ldp:isMemberOfRelationを用いるときにはメンバーシップ・トリプルの目的語）とメンバーシップ述語を定義するために柔軟性を提供しますが、メンバーを作成する時は、メンバー派生のURIは常に新しく作成されたドキュメントのURLです。LDP間接コンテナは、メンバー派生URIがいかなる資源であっても認めることでより高い柔軟性を提供しており、それは非情報資源や新しく作成された資源以外のドキュメントでありえます。これは、LDP間接コンテナのldp:insertedContentRelation述語を設定することで、作成される資源の表現に予期する述語を定義することにより行われます。これを行う方法を次の例で説明します。

4.2 作成（LDP-ICに対する資源のPOST）

前の例に引き続き、「LDP Demo」製品説明LDPC下でバグ・レポートLDPRを作成することにより、「LDP demo」製品に対する新しいバグ・レポートを作成できます。

クライアントは、バグ・レポートの表現をバグ追跡システムLDPCにPOSTします。

例35: バグを作成するためのリクエスト
Turtle:
POST /tracker/ldp-demo/ HTTP/1.1
Host: example.org
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
 
<> a bt:BugReport;
   foaf:primaryTopic <#it>;
   dcterms:title "Product A crashes when shutting down.";
   dcterms:creator </tracker/ldp-demo/johndoe> .
     
<#it> a bt:Bug .

留意すべきことの1つは、作成される資源の表現にトリプル（< >, foaf:primaryTopic , <#it>）が含まれていることです。作成リクエストが成功すれば、サーバーは、新しく作成された資源の位置で応答します。

例36: A response of creating new a bug
HTTP/1.1 201 Created
Location: http://example.org/tracker/ldp-demo/bug67
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0

作成が失敗すれば、サーバーは、エラーに応じた適切なステータス・コードで応答します。資源が作成された後に、製品A LDPCの表現は次のようになります。

例37: バグ作成後の製品LDPCの状態
Turtle:
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix bt: <http://example.org/vocab/bugtracker#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

</tracker/ldp-demo/> a ldp:IndirectContainer;
  ldp:membershipResource </tracker/ldp-demo/#it>;
  ldp:hasMemberRelation bt:hasBug;
  ldp:insertedContentRelation foaf:primaryTopic;
  dcterms:title "Product description of the LDP Demo product which is also an LDP-IC";
  ldp:contains <bug3>, <bug4> , <bug67> .
  
<#it> a bt:Product;
  dcterms:title "LDP Demo";
  bt:hasBug <bug3#it>, <bug4#it>, <bug67#it> .

ご覧のとおり、2つの新しいトリプルがコンテナに追加されました。それは（</tracker/ldp-demo/>, <ldp:contains>, </tracker/ldp-demo/bug67>）と（</tracker/ldp-demo/#it>, <bt:hasbug>, </tracker/ldp-demo/bug67#it>）です。

5. セキュリティ

読み／書き込み用リンクト・データ・アプリケーションにセキュリティ・メカニズムを提供することは、リンクト・データ・プラットフォームWGにとっての重点事項ではありません。LDPはHTTPを基にしているため、HTTPに対して定義されているメカニズムを再利用できます。一般的なウェブ・アプリケーションに適用できるセキュリティ・メカニズムのほとんどをリンクト・データ・アプリケーションに同様に適用できますが、リンクト・データ技術を活用し、リンクト・データ・アプリケーションに対する具体的なセキュリティ要件を提供することにより、リンクト・データ・アプリケーションに固有のセキュリティ・メカニズムを構築する余地はまだいくらかあります。この文脈において、LDP WGは、LDPアプリケーションのための標準的なセキュリティ・メカニズムの開発に焦点を当てた将来のイニシアチブへのインプットとして使われうるLDPアプリケーションのセキュリティ・シナリオのためのユースケースの作成を目指したアクセス・コントロールに関するWGノートを作成し始めました。

6. LDPの実装

LDP準拠となる予定の実装のリストは、LDP実装wikiページで入手可能できます。リンクト・データ・プラットフォーム1.0 - 実装報告は、各LDP実装による仕様をカバーしています。

A. 謝辞

LDP入門ドキュメントの完全なレビューおよび訂正の提案に対し、John Arwe (IBM)、Ashok Malhotra (Oracle)、and Henry Story (Apache Software Foundation)、Andrei Sambra (MIT)に謝意を表します。貴重なフィードバックに対してリンクト・データ・プラットフォームWGのすべてのメンバーにも感謝申し上げます。

B. 変更履歴

この項は非規範的です。

変更履歴は、編集者の責任により、変更に関する短い要約を挿入するもので、変更された公開草案の見出しを付けて最近の変更から順に並べてあります。

C. 参考文献

C.1 参考情報の参考文献

[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. W3C Recommendation. URL: http://www.w3.org/TR/ldp/
[LDP-BP]
Cody Burleson; Miguel Esteban Gutierrez; Nandana Mihindukulasooriya. LDP Best Practices and Guidelines. W3C Working Draft. URL: http://www.w3.org/2012/ldp/hg/ldp-bp/ldp-bp.html
[LDP-TESTS]
Raul Garcia-Castro; Fernando Serena; Steve Speicher. Linked Data Platform 1.0 Test Cases. W3C Working Draft. URL: http://www.w3.org/2012/ldp/hg/tests/ldp-testsuite.html
[LDP-UCR]
Steve Battle; Steve Speicher. Linked Data Platform Use Cases and Requirements. 13 March 2014. W3C Note. URL: http://www.w3.org/TR/ldp-ucr/
[LINKED-DATA]
Tim Berners-Lee. Linked Data Design Issues. 27 July 2006. W3C-Internal Document. URL: http://www.w3.org/DesignIssues/LinkedData.html
[WEBARCH]
Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/webarch/
[json-ld]
Manu Sporny; Gregg Kellogg; Markus Lanthaler. JSON-LD 1.0. 16 January 2014. W3C Recommendation. URL: http://www.w3.org/TR/json-ld/
[turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/