リンクト・データ通知

LDNは、ソーシャル・ウェブ・ワーキンググループが作成しているいくつかの関連仕様の1つです。別のアプローチや補足的なプロトコルに関心のある実装者は、概要ドキュメントであるソーシャル・ウェブ・プロトコルを読むことから始めるべきです。拡張性や他のプロトコルとの相互運用性のポイントを強調するために、この仕様の至る所でソーシャル・ウェブ・プロトコルの特定の小項目を参照しています。

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

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

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

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

送信者:

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

受信者:

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

利用者:

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

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

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

通知の送信先または利用元のエンドポイントである受信ボックスは、ブログの投稿、ユーザ・プロファイル、データセット、動画などの資源から発見できます。発見の開始点は、通知の対象となる資源、つまりターゲットです。あらゆる資源(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)。

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

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"

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/"
}

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="/inbox/">RSVP</a> to event
</p>

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="/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />

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>

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/> .

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

発見後、通知を送信したい送信者は、受信ボックスの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

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

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

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

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"
  ]
}

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

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

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

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

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

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"
  }
}

この項は非規範的です。

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

{
  "@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"
}

{
  "@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" }
}

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

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

{
  "@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"
  }
}

{
  "@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": "Սարվէն Չափատիշլի"
    }
  }
}

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

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

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

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

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

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

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

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

この仕様は、個人を特定できる情報を扱いますか?

通知ペイロードには、送信者や受信者を識別するデータを含むデータが含まれている場合があります。通知データへのアクセスは、受信者の管理下にあります。機密情報を送信する場合には、送信者は、受信者が受信ボックスに、コンテンツを公開して閲覧できるようなアクセス制御を実装するかもしれないことを認識しておく必要があります。

この仕様は、価値の高いデータを扱いますか?

通知ペイロード内の個人を特定できる情報と同様の意味(上記のとおり)。

この仕様は、複数の閲覧セッションにまたがって持続する新たな状態をオリジンに導入しますか?

いいえ。

この仕様は、持続的なクロス・オリジンの状態をウェブで公開しますか?

いいえ。

この仕様は、現在アクセスできないその他のデータをオリジンに公開しますか?

いいえ。

この仕様は、新たなスクリプトの実行/読み込みメカニズムを可能としていますか?

いいえ。

この仕様は、ユーザの所在へのアクセスをオリジンに認めていますか?

いいえ。

この仕様は、ユーザのデバイス上のセンサーへのアクセスをオリジンに認めていますか?

いいえ。

この仕様は、ユーザのローカル・コンピューター環境側へのアクセスをオリジンに認めていますか?

いいえ。

この仕様は、他のデバイスへのアクセスをオリジンに認めていますか?

いいえ。

この仕様は、ユーザ・エージェントのネイティブなUIを制御する手段をオリジンに認めていますか?

いいえ。

この仕様は、一時的な識別子をウェブに公開しますか?

いいえ。

この仕様は、当事者と第三者のコンテキストの挙動を区別しますか?

いいえ。

この仕様は、ユーザ・エージェントの「シークレット」モード(incognito mode)のコンテキストにおいてどのように動作すべきですか?

ユーザが「シークレット」であるとウェブ・サイトが判断できないような方法で動作します。

この仕様は、ユーザのローカルなデバイスにデータを保持しますか?

いいえ。

この仕様には「セキュリティに関する留意点」と「プライバシーに関する留意点」の項がありますか?

:)

この仕様は、デフォルトのセキュリティ特性をダウングレードすることを認めていますか?

いいえ。

• 例の構文エラーを修正
• 「ソーシャル・ウェブ・グループ憲章」への「返信先」リンクの追加
• 仕様の過去のバージョンへのリンクを追加
• 参考文献を更新

• 謝辞を更新

• 「謝辞」を追加
• 注の通知とリクエストURIの暗黙の応答コードを明確化
• 参考文献を更新

• 「留意点」に「自然言語のコンテンツ」の項を追加
• PubSubへの参照を修正
• 実装レポートとテスト・スイートにURLを追加
• SVGにキャプションを追加
• AS2のbibフラグメントを修正
• ペイロード検証を言い換え
• 「認証済み受信ボックス」のセキュリティ・ガイドを追加

• 例を追加・更新
• HTTP HEAD/GETの発見の表現を改善
• 編集上変更: 文法、言い換え
• Accept-Postの参照を修正し、OPTIONSでの表示について明示
• 国際化レビュー(例)のフィードバックを統合

• 誤植とリンクを修正
• 「送信」、「受信」、「利用」の順に項を並べ替え
• 例を更新
• RFC7231への参照を追加
• URI発見の表現を明確化
• 「留意点」の非規範的な項に小見出しを追加
• 概要図を追加
• 「留意点」の「発見の再試行」に関する非規範的な小項目を追加
• 「発見」に対して丁寧であることを言及
• 「悪用の防止」をそれぞれの規範的な項に移動
• 「送信者の検証」を受信者に移動
• 「ActivitStreams 2.0のサポート」を「留意点」に移動
• 「ペイロードの検証」を「注」として「利用」に移動
• 規範および一部の非規範な項を「留意点」から、より前の項に移動
• 「セキュリティとプライバシーのレビュー」の項を追加
• 「はじめに」を更新

• 誤植、句読点、命名
• 「終了基準」を追加
• Acceptヘッダーの使用・省略時の動作を明確化
• Linkヘッダー・フィールドの関係の主語に関する注を追加
• 可能なLinkヘッダーに対するGETを追加し、ターゲットURLの主語URI(受信ボックス)を明確化
• 「要約」を修正
• ターゲットの所有権に関する留意点を追加
• 「あらゆる資源が独自の受信ボックスを持ちえる」と言及
• 「通知の購読」の項を追加

• 例の改善: 更新、構文修正、httpsの@context
• 誤植、句読点、名称
• ペイロードに関して参考情報の裁量を使用