リンクト・データ通知

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

要約

リンクト・データ通知は、アプリケーション(送信者)がサーバー(受信者)にメッセージをプッシュできる方法、および他のアプリケーション(利用者)がそのメッセージを取得できる方法を記述するプロトコルです。あらゆる資源は、メッセージ受信のエンドポイント(受信ボックス(Inbox))を公言(advertise)できます。メッセージはRDFで表され、あらゆるデータを含めることができます。

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

ステータスの更新(2017年5月): 2017年5月22日に概要図のリンクをインプレース修正しました。誤った内部アンカーを指していました。

ステータスの更新(2017年9月): 2017年9月5日22日(訳注: 誤記と思われる。)に概念のURIをインプレース修正しました。誤った内部URIを指していました。

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

このドキュメントは、ソーシャル・ウェブ・ワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、[email protected](購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。

ワーキンググループの実装報告書を参照してください。

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

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

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

1. はじめに

ウェブ上のデータは、特定のシステム内に閉じ込めたり、それを作成したアプリケーションでしか読めないようにしたりすべきではありません。ユーザは、アプリケーションを自由に切り替えて、それらの間でデータを共有できるべきです。アプリケーションは、活動、相互作用、新しい情報に関する通知を生成し、それをユーザに提示したり、さらに処理したりすることができます。

リンクト・データ通知(LDN;Linked Data Notifications)は、通知の生成方法に関係なく、アプリケーションにまたがる通知の共有と再利用をサポートします。これにより、より多くのモジュール型のシステムが可能になり、データを表示・利用するアプリケーションからデータ・ストレージを切り離すことができます。このプロトコルは、通知の送信者、受信者、利用者(これらは、別々に実装され、様々な技術スタック上で動作する)が、シームレスに連携し、ウェブ上の相互作用の分散化に貢献できるようにすることを目的としています。

この仕様では、通知を一時的または非永続的なエンティティーとして扱うのではなく、通知の概念を、独自のURIを持つ個別のエンティティーとして使用できるようにします。それによって、通知を取得して再利用することができます。我々は、ソーシャルなものであれ何であれ、様々なアプリケーション領域をサポートしているため、通知の内容は定義するアプリケーションに委ねられています。通知の認証と検証は推奨されますが、通知の種類やアプリケーション領域によってニーズが異なるため、それを行うメカニズムは受信者と利用者の裁量に委ねられています。

1.2 概要

リンクト・データ通知の概要

送信者は、人間または自動プロセスにより始動され、サーバーに通知を配信します。通知は、受信者の注意を喚起するためのデータで、例えば、友人からの個人的なメッセージ、ピンバック(pingback)リンク、ブログ投稿に関するコメント、コラボレーションへの招待、カレンダーのリマインダー、科学的観察などです。

送信者は、通知を送信するターゲット資源を選択します。次に、送信者はターゲットの受信ボックスの場所を発見し、そこに通知を送信します。あらゆる資源は受信ボックスを公言することができます。受信者は、利用者が使用できるように(適切なアクセス制御に従って)通知データを公開します。

利用者は、送信者と同じ方法で受信ボックスの場所を発見し、通知に対してさらに処理を実行したり、他のデータと組み合わせたり、適切な人間が読める方法でシンプルに提示したりできます。

1.3 要約

送信者と利用者は、資源のHTTP Linkヘッダーや本文のrelを通じて、資源の受信ボックスのURLを発見します。

送信者:

アプリケーションのニーズに応じて通知の本文を作成します。
JSON-LDまたはサーバーが受け入れ可能な別のシリアル化に本文を含めて、POSTリクエストを行うことにより、通知を受信ボックスのURLに送信します。

受信者:

以前に受け入れられた通知のURLのリストを用いて、受信ボックスのURLに対するGETリクエストに応答します。
JSON-LD(またはオプションで他のシリアル化)を用いて、個々の通知のURLに対するGETリクエストに応答します。
受信ボックスのURLでPOSTリクエストを受け入れ、通知を作成します。
オプションで、受信ボックスに送信される通知に制約を適用します。

利用者:

GETリクエストで受信ボックスのURLのコンテンツを取得し、アプリケーションのニーズに応じて用います。

1.4 リンクト・データ・プラットフォームとの関係

LDNは、通知の送信と利用のためのリンクト・データ・プラットフォーム[LDP]の特殊な使い方です。これは、LDPの完全な実装に依存するものではなく、実装が容易なサブセットです。この仕様を理解するためには、LDPの知識を持っている必要はありませんが、知識がある人は、一部の概念を知っていることに気づくでしょう。このドキュメントでは、分散化された相互運用可能な方法で通知を容易に交換できるようにするために必要な特定の機能について説明します。LDNの受信ボックスはBasicContainerに相当します。

2. 適合性

このドキュメントの「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である／要求される(REQUIRED)」、「することになる(SHALL)」、「することはない(SHALL NOT)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「することができる／してもよい(MAY)」、「選択できる／任意である(OPTIONAL)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。

2.1 適合クラス

LDNの実装は、送信者、受信者、または利用者でありえます。これらのそれぞれの役割の適合基準については、この仕様の各項で記述しています。

3. プロトコル

この項では、通知の配信や読み取りが行われるURL(受信ボックス)の発見と配信の仕組みについて説明します。通知内容はペイロードに記述されます。

3.1 発見

通知の送信先または利用元のエンドポイントである受信ボックスは、ブログの投稿、ユーザ・プロファイル、データセット、動画などの資源から発見できます。発見の開始点は、通知の対象となる資源、つまりターゲットです。あらゆる資源(RDFであってもなくても)が独自の受信ボックスを持ちえるため、発見を開始するための最も適切なターゲット資源の選択は、送信者や利用者の裁量に委ねられています。

送信者と利用者は、受信ボックスのURLを発見するために次を行います。

ターゲットURLでHTTP HEADまたはGETリクエストを行い、relの値がhttp://www.w3.org/ns/ldp#inboxであるLinkヘッダーを用います。
ターゲットURLでHTTP GETリクエストを行い、エンコードされたRDFグラフにhttp://www.w3.org/ns/ldp#inboxという型の関係を含んでいるRDF表現[RDF 1.1]を取得します。この関係の主語はターゲット、目的語は受信ボックスです。

これらはどちらの順序でも実行できますが、最初の方法で受信ボックスが発見できなかった場合は、2番目の方法を試さなければなりません(MUST)。送信者と利用者は、特にフラグメント識別子を持つURIをターゲットとする場合には、Linkヘッダーの発見を省略すべきです(SHOULD)。

注

ターゲットにフラグメント識別子が含まれている場合、そのフラグメントはサーバーに対するリクエストの一部ではありません。送信者と利用者は、Linkヘッダーにある受信ボックスは、フラグメントのない、解決されたURLのものであることを認識しているべきです。[セマンティック・ウェブのためのクールなURI - ハッシュURI]を参照してください。

資源は受信ボックスを1つのみ公言しなければなりません(MUST)。例えば、すべてのブログ投稿への返信用とすべての自分の写真の共有用に同じ受信ボックスを用いるなど、1つの受信ボックスは、複数の資源で使用できます(MAY)。

発見の例1: リンク・ヘッダー

HEAD /article HTTP/1.1
Host: example.org
Accept: application/ld+json

HTTP/1.1 200 OK
Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox"

HEADリクエストで受信ボックスを発見し、Linkヘッダーを受信する場合のリクエストと応答。

発見の例2: JSON-LD

GET /profile HTTP/1.1
Host: example.org
Accept: application/ld+json

HTTP/1.1 200 OK
Content-Type: application/ld+json

{
  "@context": "http://www.w3.org/ns/ldp",
  "@id": "http://example.org/profile",
  "inbox": "http://example.org/inbox/"
}

JSON-LDを取得するためにGETリクエストで受信ボックスを発見。JSON-LDコンパクト形式で応答。

発見の例3: HTML(表示あり)

GET /event HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<p about="http://example.org/event" typeof="http://schema.org/Event" lang="en">
  <a rel="http://www.w3.org/ns/ldp#inbox" href="/http/www.asahi-net.or.jp/inbox/">RSVP</a> to event
</p>

HTMLを取得するためにGETリクエストで受信ボックスを発見。受信ボックスのリンクは人間に表示され、機械が受信ボックスのURLを発見できるようにRDFaでマークアップされている。

発見の例4: HTML(表示なし)

GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<link href="/http/www.asahi-net.or.jp/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />

HTMLを取得するためにGETリクエストで受信ボックスを発見。機械による発見用にRDFaでマークアップし、link要素で表している非表示の受信ボックス。

発見の例5: HTML(表示なし)

GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<section id="results" about="#results"
  property="http://www.w3.org/ns/ldp#inbox" resource="/inbox/">
</section>

HTMLを取得するためにGETリクエストで受信ボックスを発見。フラグメントURIで識別される資源がターゲットになりえるように、RDFaのproperty属性で表している非表示の受信ボックス。

発見の例6: Turtle

GET / HTTP/1.1
Host: csarven.ca
Accept: text/turtle, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/turtle;charset=utf-8

<http://csarven.ca/#i>
  <http://www.w3.org/ns/ldp#inbox> <http://csarven.ca/inbox/> .

Turtleを取得するためのGETリクエストで受信ボックスを発見。

特にこのプロトコルを認識していない可能性があるサーバーを考慮した、発見の実行方法に関する推奨事項に関しては、ソーシャル・ウェブ・プロトコルを参照してください。

3.2 送信者

発見後、通知を送信したい送信者は、受信ボックスのURLにPOSTリクエストでその通知を配信しなければなりません(MUST)。送信者は、リクエストが成功したときの応答として、201 Created(生成)(Location Linkヘッダー付き)または202 Accepted(受理)を期待できます。

送信者はOPTIONSリクエストを用いてサーバーが受け入れるRDFコンテンツ・タイプを判断し、返されたAccept-Postヘッダー[Accept-Post]の値に従ってリクエスト本文の通知をシリアル化できます(MAY)。あるいは、POSTリクエストの本文に、Content-Type: application/ld+jsonというヘッダーを持つJSON-LDの通知ペイロードが含まれていなければなりません(MUST)。Content-Typeヘッダーには、profile URI[RFC6906]を含めることができます(MAY)。

送信者は、認証や承認の目的で、Authorization: Bearer XXXなどの追加のヘッダーやコンテンツを含めることができます(MAY)。

認証を必要としないローカルホスト上でリッスンするサービスを送信者が持っている場合、悪意のあるスクリプトが受信ボックスのエンドポイントで実行され、送信者が自身に任意のPOSTリクエストを送信する可能性があります。送信者は、ローカルホストやループバックIPアドレスである受信ボックスにPOSTリクエストを行うべきではありません(SHOULD NOT)。

送信の例(リクエスト)

POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

受信ボックスに送信するリクエストの例。

送信の例(応答)

HTTP/1.1 201 Created
Location: http://example.org/inbox/5c6ca040

受信ボックスのPOSTリクエストへの応答の例。

3.3 受信者

受信者は、受信ボックスのURLにおけるGETとPOSTのリクエストをサポートしなければなりません(MUST)。LDPの用語では、受信ボックスはコンテナです。

3.3.1 通知の受信

POSTリクエストの受信時に、通知資源が正常に処理された場合、受信者は、201 Createdというステータス・コードと、通知データを取得できるURLに設定したLocationヘッダーで応答しなければなりません(MUST)(利用者を参照)。リクエストが非同期で処理されるようにキューに入れられた場合、受信者は202 Acceptedというステータス・コードで応答し、リクエストのステータスに関する情報を応答の本文に含めなければなりません(MUST)。

通知に制約を適用する受信者(制約を参照) は、制約が満たされなければ、通知の処理に失敗し、適切な4xxのエラー・コードを返すべきです(SHOULD)。

受信者は、リクエストの本文がJSON-LDで、Content-Type: application/ld+jsonを持つ通知を受け入れなければならず(MUST)、これにはprofile URI[RFC6906]を含むことができます(MAY)。

受信者は他のRDFコンテンツ・タイプ(例えば、text/turtle、text/html)を受け入れることもでき(MAY)、その場合は、受信ボックスのURLのOPTIONSリクエストへの応答として、受け入れるコンテンツ・タイプをAccept-Post[Accept-Post]ヘッダーで公言すべきです(SHOULD)。

受信者の例1: optionsの応答

OPTIONS /inbox/ HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS, POST
Accept-Post: application/ld+json, text/turtle

Accept-PostでOPTIONSリクエストに応答する受信者。

受信者の例2: postの応答

POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

HTTP/1.1 201 Created
Location: http://example.org/inbox/92d72f00

通知の作成により、受信ボックスのPOSTリクエストに応答する受信者。

3.3.2 受信ボックスのコンテンツの利用者への提供

受信ボックスのGETリクエストが成功した場合、リクエスト側がアクセスできることを前提として、通知のURIを含んだHTTP 200 OKを返さなければなりません(MUST)(該当する場合は4xxのエラー・コードを返す)。受信者は、利用者がアクセスできる受信ボックス内の通知のURIのみを列挙できます(MAY)。受信ボックスのURLでは、通知の参照用にhttp://www.w3.org/ns/ldp#containsという述語を用いなければなりません(MUST)。

個々の通知はRDF情報源でなければなりません(MUST)。RDF以外の資源が返された場合は、利用者はそれを無視できます(MAY)。通知のURIのGETリクエストが成功した場合、リクエスト側がアクセスできることを前提として、HTTP 200 OKを返さなければなりません(MUST)(該当する場合は4xxのエラー・コードを返す)。

JSON-LDのコンテンツ・タイプはすべての資源で利用できなければなりませんが(MUST)、クライアントは他のコンテンツ・タイプを優先するAcceptヘッダーを送信することもできます(RFC7231の3.4項 - 内容交渉)。クライアントがAcceptヘッダーを送信しない場合は、サーバーは、JSON-LDや、同じ情報を忠実に伝える任意の形式(例えば、Turtle)でデータを送信できます。

受信ボックス自体に関する追加の記述が返される場合もあります(MAY)(制約)。

注

この仕様では、受信ボックスの通知のリストを提供するページングのメカニズムを定義していません。実装でページングを有効にしたい場合は、効率的な取得を可能とするために、リンクト・データ・プラットフォーム・ページング1.0、アクティビティ・ストリームズ2.0のコレクションなどの既存のメカニズムを用いるのが良いかもしれません。

受信者の例3: GETの応答

GET /inbox/ HTTP/1.1
Host: example.org
Accept: application/ld+json
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6

HTTP/1.1 200 OK
Content-Type: application/ld+json
Content-Language: en

{
  "@context": "http://www.w3.org/ns/ldp",
  "@id": "http://example.org/inbox/",
  "contains": [
    "http://example.org/inbox/5c6ca040",
    "http://example.org/inbox/92d72f00"
  ]
}

通知のリストで受信ボックスのGETリクエストに応答する受信者。

3.3.3 送信者の検証

受信者は、通知の送信者を検証すべきです(SHOULD)。例えば、次のような方法によります。

受信ボックスへの書き込みアクセス権を持つ送信者のホワイトリストを保有する。
すべての送信者に関する受信者の知識を強制するために認証を要求する。
送信元のドメインから通知のコピーを取得して、そのオリジンを検証する。
通知に添付されているデジタル署名を確認する。

3.3.4 悪用の防止

受信者は、不当な通知がサーバーで作成され、受信ボックスによって公開されないように、制約を用いてフィルタリングを行うべきです(SHOULD)。

受信者は、信頼できる送信者のホワイトリストへの書き込みを制限するために、受信ボックスのURLへのアクセス制御の実装を検討できます。

3.4 利用者

利用者は、受信ボックスのURLでGETリクエストを行うことにより、受信ボックスの通知のURIを取得します(このURLの発見に関しては、発見を参照)。

通知のURIは、受信ボックスのURLのhttp://www.w3.org/ns/ldp#containsという述語により発見できなければなりません(MUST)(受信ボックスのコンテンツの例を参照)。

受信ボックスや個々の通知を取得する際に、利用者は、Acceptヘッダーを明示的に設定して、優先するコンテンツ・タイプを示すべきです(SHOULD)(JSON-LDを含む)。個々の通知 — あるのか、何件なのか、または特定の基準(例えば、コンテンツの長さ、タイムスタンプ)に従うのか — のフェッチは、利用者の裁量に委ねられています。

利用者は、認証や承認の目的で、追加のヘッダーやコンテンツを含めることができます(MAY)。

利用者は、自身の裁量で、ペイロードから情報を追加でフェッチしたり推論したりする(例えば、通知で参照されている資源を逆参照してコンテンツをフェッチする)ことができます(MAY)。利用者は、処理や使用をさらに行う前に、通知を、受信ボックスがアナウンスしている制約と照合したいかもしれません(MAY)。

注

通知のためにフェッチされるURIには、リクエストされたURI自体とは異なる1つ以上の主語であるIRIを持つRDFステートメントを含むことができます(may)。利用者はまた、リクエストされたURIを主語とする何らかのトリプルが通知に含まれていると仮定すべきではありません。これは、通知の本文で相対IRIを用いる場合にも当てはまります。実装が、通知のURIを、通知ペイロードからのRDFを含むグラフとして扱いたい場合があります。

注

利用者は、受信ボックスに何でもポストできることを認識しているべきです(受信者が設定する制限にもよるが、これに関しては、このプロトコルでは定義していない)。そのため、利用者は、通知データを利用する場合に、コンテンツの信憑性を確認する際に用心が必要かもしれません。

利用者の例: 通知の取得

GET /inbox/14a792f0 HTTP/1.1
Host: example.org
Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6

HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    { "@language": "en" }
  ],
  "@id": "http://example.org/inbox/14a792f0",
  "@type": "Announce",
  "actor": {
    "@id": "http://csarven.ca/#i",
    "name": "Sarven Capadisli"
  },
  "object": {
    "@context": "http://www.w3.org/ns/anno.jsonld",
    "@id": "http://example.net/note",
    "@type": "Annotation",
    "motivation": "http://www.w3.org/ns/oa#assessing",
    "rights": "http://creativecommons.org/licenses/by/4.0/"
  },
  "target": "http://example.org/article",
  "updated": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2016-06-28T19:56:20.114Z"
  }
}

受信ボックスで発見された個々の通知でのGETリクエストの結果。

4. ペイロード

受信者が別のRDF構文と交渉済みでない限り、通知のペイロードはJSON-LDでなければなりません(MUST)。様々なユースケースを可能とするために、ペイロードの実際の語彙はここでは意図的に規定していません。

4.1 ペイロードの例

この項は非規範的です。

ペイロードの例1

{
  "@context": "http://schema.org/",
  "@id": "http://example.net/note#foo",
  "citation": { "@id": "http://example.org/article#results" }
}

schema.orgの語彙を用いて1つのステートメントで記述された引用。

ペイロードの例2

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

ActivityStreams 2.0の語彙を用いて記述された、日付と当事者(actor)を含む、ある資源から別の資源へのアナウンス。

ペイロードの例3

{
  "@context": { "pingback": "http://purl.org/net/pingback/" },
  "@id": "",
  "@type": "pingback:Item",
  "pingback:source": { "@id": "http://example.net/note#foo" },
  "pingback:target": { "@id": "http://example.org/article#results" }
}

セマンティック・ピンバック語彙で記述されたピンバック通知。

ペイロードの例4

{
  "@context": "http://schema.org/",
  "@id": "",
  "@type": "RsvpAction",
  "event": { "@id": "http://example.org/event" },
  "agent": { "@id": "https://rhiaro.co.uk/#me" }
}

schema.org語彙によって記述されたイベントRSVP。

通知には、データに関する特定の外部資源やオリジンを必ずしも参照せずに、独自のURIを持つ複数の資源への参照を含む、任意の情報を含めることができます。そのような通知を利用者がリクエストした場合には、受信者は、最初に送信されたすべてのトリプルを返すことが期待されています。

ペイロードの例5

{
  "@context": {
    "@language": "en",
    "sioc": "http://rdfs.org/sioc/ns#",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "",
  "@type": "sioc:Comment",
  "sioc:reply_of": { "@id": "http://example.org/article" },
  "sioc:created_at": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2015-12-23T16:44:21Z"
  },
  "sioc:content": "This is a great article!",
  "sioc:has_creator": {
    "@id": "http://example.org/profile",
    "@type": "sioc:UserAccount",
    "sioc:account_of": { "@id": "http://example.org/profile#alice" },
    "sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },
    "foaf:name": "Alice"
  }
}

SIOC(Semantically Interlinked Online Communities)とFOAF(Friend-of-a-Friend)の語彙で記述された、コメントとそのコメントを作成したユーザに関するデータを含んでいる通知。

ペイロードの例6

{
  "@context": [{"prov": "http://www.w3.org/ns/prov#"}],
  "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
  "@type": "prov:Activity",
  "http://www.w3.org/2000/01/rdf-schema#label": {
    "@language": "en",
    "@value": "Make it so"
  },
  "prov:endedAtTime": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2016-06-14T20:57:39.000Z"
  },
  "prov:generated": {
    "@id": "http://example.org/entity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
    "@type": "prov:Entity",
    "prov:specializationOf": { "@id": "http://example.org/entity/file" },
    "prov:wasGeneratedBy": {
      "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7"
    }
  },
  "prov:wasAssociatedWith": {
    "@id": "http://csarven.ca/#i",
    "@type": "prov:Agent",
    "http://xmlns.com/foaf/0.1/name": {
      "@language": "hy",
      "@value": "Սարվէն Չափատիշլի"
    }
  }
}

来歴語彙によって記述された変更履歴のエントリー。

5. セキュリティ、プライバシー、コンテンツに関する留意点

この項は非規範的です。セキュリティとプライバシーの規範的な要件は、それが最も該当する仕様の項で呼び掛けを行っています。

5.1 制約

受信ボックスのURLは、HTTP Linkヘッダーまたはhttp://www.w3.org/ns/ldp#constrainedByというrel値を持つ資源の本文を介して、独自の制約(例えば、SHACL、ウェブ・アノテーション・プロトコル)をアナウンスできます。送信者は制約の仕様に準拠すべきで、そうしない場合は、受信者が通知を拒否して適切な4xxエラー・コードを返す場合があります。

5.2 ターゲットの所有権

受信ボックス(ターゲット)を公言する資源の公開者は、信頼しているサーバーでこれを行う必要があります。公開者は、ヘッダーまたはコンテンツへの第三者のアクセスにより、通知がリダイレクトされる可能性があることを認識している必要があります。

5.3 通知の購読

この仕様では、利用者が受信者からの通知をプル(pull)によって読む方法について記述していますが、利用者は、着信型の通知や受信ボックスの内容の変更をプッシュしてもらいたいと思うかもしれません。同様に、受信者は特定の送信者からの通知をリクエストしたいと思うかもしれません。この種の購読メカニズムは範囲外ですが、送信者、受信者、利用者がそのようなアレンジを行うことは禁止されていません。購読を有効にしたい実装では、ActivityPub、WebSub、WebSocketプロトコル、HTTPウェブ・プッシュなどの既存のメカニズムを用いるのが良いかもしれません。

5.4 Activity Streams 2.0のサポート

Activity Streams 2.0コアのサポートを希望する受信者の実装では、コンテンツ・タイプと語彙の同等性に関するソーシャル・ウェブ・プロトコル - Inbox Interopを参照できます。

5.5 自然言語のコンテンツ

連合型ネットワークでは、ユーザの国際的な基盤を構築することが重要です。一部のLDNの相互作用では、HTMLのフラグメントや要約フィールド(summary field)などの自然言語のテキストでコンテンツを返すことができます。各項目の表現を複数の言語で提供することは、すべての状況で実現できるとは限りません。実装では、HTTP Accept-Languageヘッダーを用いて交渉し、与えられたリクエストに対して送信するために最も適切な言語表現を選択するなど、利用可能な言語の発見および/または返された言語の交渉を行う手段を提供することが推奨されます。

5.6 認証済み受信ボックス

受信者が、送信者や利用者に認証を求める場合、受信者は、他のエラー・コードを含む他のデータを返す前に、彼らの証明書の有効性を確認すべきです。例えば、受信者は最初に受信ボックスの存在を確認すべきではなく、リクエストを行った者が未検証であれば404 Not Foundを返すべきです。

トークンの受け渡しを伴う認証は、HTTPS経由で行わなければなりません。

5.7 セキュリティとプライバシーの点検

自己点検質問票: セキュリティとプライバシーに従って、下記の質問で、この仕様のセキュリティとプライバシーに関する留意点の概要を把握できます。

この仕様は、個人を特定できる情報を扱いますか?: 通知ペイロードには、送信者や受信者を識別するデータを含むデータが含まれている場合があります。通知データへのアクセスは、受信者の管理下にあります。機密情報を送信する場合には、送信者は、受信者が受信ボックスに、コンテンツを公開して閲覧できるようなアクセス制御を実装するかもしれないことを認識しておく必要があります。
この仕様は、価値の高いデータを扱いますか?: 通知ペイロード内の個人を特定できる情報と同様の意味(上記のとおり)。
この仕様は、複数の閲覧セッションにまたがって持続する新たな状態をオリジンに導入しますか?: いいえ。
この仕様は、持続的なクロス・オリジンの状態をウェブで公開しますか?: いいえ。
この仕様は、現在アクセスできないその他のデータをオリジンに公開しますか?: いいえ。
この仕様は、新たなスクリプトの実行/読み込みメカニズムを可能としていますか?: いいえ。
この仕様は、ユーザの所在へのアクセスをオリジンに認めていますか?: いいえ。
この仕様は、ユーザのデバイス上のセンサーへのアクセスをオリジンに認めていますか?: いいえ。
この仕様は、ユーザのローカル・コンピューター環境側へのアクセスをオリジンに認めていますか?: いいえ。
この仕様は、他のデバイスへのアクセスをオリジンに認めていますか?: いいえ。
この仕様は、ユーザ・エージェントのネイティブなUIを制御する手段をオリジンに認めていますか?: いいえ。
この仕様は、一時的な識別子をウェブに公開しますか?: いいえ。
この仕様は、当事者と第三者のコンテキストの挙動を区別しますか?: いいえ。
この仕様は、ユーザ・エージェントの「シークレット」モード(incognito mode)のコンテキストにおいてどのように動作すべきですか?: ユーザが「シークレット」であるとウェブ・サイトが判断できないような方法で動作します。
この仕様は、ユーザのローカルなデバイスにデータを保持しますか?: いいえ。
この仕様には「セキュリティに関する留意点」と「プライバシーに関する留意点」の項がありますか?: :)
この仕様は、デフォルトのセキュリティ特性をダウングレードすることを認めていますか?: いいえ。

A. 終了基準

この仕様は、少なくとも2つの独立した相互運用可能な個々の機能の実装により、勧告案に進みました。個々の機能は、異なる製品によって実装されました。すべての機能を1つの製品で実装する必要はありませんでした。

独立した実装は様々な関係者によって開発されており、この仕様の実装に直接関連する別の適格な実装コードから共有、再利用、または派生することはできません。
この仕様で定義しているように、送信者/利用者が受信者にリクエストを行い、受信者が予期される応答を送信すると、送信者と受信者の間、または利用者と受信者の間で相互運用が発生します。
実装は、仕様の対応する適合クラスを実装するLDNの送信者、受信者、または利用者です。

終了基準を評価する目的で、次のそれぞれを機能と見なしました。

Linkヘッダーにより、特定の資源の受信トレイを公言します。
資源の本文により、特定の資源の受信ボックスを公言します。
特定のターゲットの受信ボックスに通知を送信します。
通知を受信し、どのように処理されたのか、受け入れられたのかどうかに応じて、適切なステータス・コードで応答します。受信ボックスのリストを用いて受信ボックスのGETリクエストに応答し、その表現を用いて個々の通知のGETリクエストに応答します。
特定のターゲットの受信ボックスのリストを読み取る。
特定のターゲットの受信ボックス内の個々の通知を読み取ります。

C. 変更履歴