リンクドデータ通知

LDNは、ソーシャルWebワーキンググループが策定している関連仕様のひとつです。代替アプローチや補完プロトコルに関心のある実装者は、まず概要文書Social Web Protocolsをお読みください。Social Web Protocolsの特定のサブセクションは、本仕様において他のプロトコルとの拡張性・相互運用性を強調する箇所で参照されています。

送信者（sender）は、人間または自動プロセスによってトリガされ、サーバーへ通知を送ります。この通知は受信者（receiver）への注意喚起を目的としたデータです。たとえば：友人からの個人的なメッセージ、pingbackリンク、ブログ記事へのコメント、コラボレーションへの招待、カレンダーのリマインダー、科学的な観測結果などです。

送信者は通知送信先の対象リソースを決め、送信先のInboxの場所を発見し、そこに通知を送ります。どのリソースもInboxを広告できます。受信者は（適切なアクセス制御のもとで）通知データを利用者のために公開します。

利用者（consumer）も送信者と同じ方法でInboxの場所を発見し、通知をさらに処理したり、他のデータと統合したり、もしくは単純に人間が読める形で表示することもできます。

送信者と利用者は、リソースのInbox URLを、HTTP Linkヘッダーやリソースの本体にある関連付けから発見します。

送信者（Sender）：

• アプリケーションの要件に従って通知の本文を作成します。
• 通知をInboxのURLへPOSTリクエストで送信し、本文はJSON-LDやサーバーが受理可能な他のシリアライズで送ります。

受信者（Receiver）：

• InboxのURLへのGETリクエストに対して、すでに受理した通知のURLの一覧を返します。
• 個々の通知URLへのGETリクエストには、JSON-LD（または任意で他のシリアライズ）で応答します。
• InboxのURLへのPOSTリクエストで通知の新規作成を受け付けます。
• 任意で、Inboxへ送られる通知に制約を課すこともできます。

利用者（Consumer）：

• Inbox URLの内容をGETリクエストで取得し、アプリケーションの要件に従って利用します。

LDNは通知の送信・消費のためのLinked Data Platform [LDP] の応用例であり、LDP全体の実装は不要で、最小限でも実装しやすい部分集合です。LDPの知識がなくとも本仕様は理解できますが、LDPに馴染みのある方にはいくつかの概念が馴染み深いでしょう。本仕様では通知の分散的かつ相互運用可能な交換を容易にするために必要な特徴のみを具体的に説明します。LDNのInboxはLDPのBasicContainerに相当します。

LDN実装 は送信者、受信者、利用者のいずれかであり得ます。それぞれの役割の適合要件は本仕様の該当セクションに記載されています。

Inbox（通知が送信される、またはそこから消費されるエンドポイント）は、ブログ記事、ユーザープロファイル、データセット、ビデオなど任意のリソースから検出できます。検出の出発点は通知が送られる、または関連するリソース、すなわちtargetです。どのリソース（RDFでも非RDFでも）が独自のInboxを持ち得るため、どのtargetリソースから検出を始めるかは送信者またはコンシューマの裁量によります。

送信者とコンシューマはInboxのURLを検出するために次の操作を行います：

• ターゲットURLに対してHTTPのHEADまたはGETリクエストを行い、rel値がhttp://www.w3.org/ns/ldp#inboxであるLinkヘッダーを使用する。
• ターゲットURLに対してHTTPのGETリクエストを行い、RDF表現（[RDF 1.1]）を取得する。そのエンコードされたRDFグラフにhttp://www.w3.org/ns/ldp#inbox型の関係が含まれていることを利用する。関係の主語がtargetで、オブジェクトがInboxである。

これらはどちらの順序でも実行できますが、最初の方法でInboxが見つからなかった場合は、二番目の方法がMUST試みられるべきです。送信者とコンシューマは、フラグメント識別子を持つURIを明示的にターゲットとする場合はLinkヘッダーによる検出をSHOULD省略するべきです。

リソースはMUSTひとつのInboxのみを公開しなければなりません。ひとつのInboxは複数のリソースで共有して使ってもMAY（例：すべてのブログ投稿への返信やすべての写真の共有に同じInboxを使う場合など）。

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

サーバーがこのプロトコルを認識していない可能性のあるサーバーに対する検出方法については、Social Web Protocolsの推奨を参照してください。

検出（discovery）の後、通知を送信したい送信者は、InboxのURLに対してMUST POSTリクエストで配信しなければならない。送信者は成功したリクエストに対して201 Created（Locationヘッダー付き）または202 Acceptedを期待できます。

送信者は、サーバーが受け入れるRDFコンテンツタイプを判断するためにOPTIONSリクエストを使用することがMAYあります。サーバーが返すAccept-Postヘッダーの値に従って通知をシリアライズします。そうでない場合は、POSTリクエストの本文はJSON-LD形式の通知ペイロード（payload）を含まなければならない（ヘッダーはContent-Type: application/ld+json）。Content-Typeヘッダーはprofile URIを含めることがMAYあります（[RFC6906]参照）。

送信者は認証や認可の目的で追加のヘッダーやコンテンツ（例：Authorization: Bearer XXX）を含めることがMAYあります。

送信者が認証不要でlocalhostで待機するサービスを持っている場合、悪意あるスクリプトがInboxエンドポイントで実行され、送信者自身に任意のPOSTを行わせる可能性があります。そのため送信者は localhost やループバック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

受信者はInboxのURLでGETおよびPOSTリクエストをサポートしなければならない（MUST）。 LDPの用語では、InboxはContainerです。

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

コンシューマはInboxのURLに対してGETリクエストを行い、Inbox内の通知のURIを取得します（Inbox URLの取得方法はdiscoveryを参照）。

通知のURIはInbox URLのhttp://www.w3.org/ns/ldp#contains述語を通じて発見可能でなければなりません（Inbox内容の例を参照）。

Inboxまたは個々の通知を取得する際、コンシューマは好ましいコンテンツタイプ（JSON-LDを含む）を示すために明示的にAcceptヘッダーを設定することがSHOULD推奨されます。個々の通知をいつ、いくつ、あるいは特定の条件（例：コンテンツ長、タイムスタンプ）に従って取得するかはコンシューマの裁量です。

コンシューマは認証や認可の目的で追加のヘッダーやコンテンツを含めることがMAYあります。

コンシューマはペイロードからの追加取得（例：通知内で参照されているリソースをデリファレンスしてその内容を取得する）や推論を任意で行ってもよく、通知をさらに処理・利用する前にInboxが公表する制約を確認することも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を持つ複数のリソースへの参照も含めることができます。特定の外部リソースやデータの出典に必ずしも言及する必要はありません。消費者によって通知がリクエストされたとき、受信者は最初に送られたすべての三つ組（triple）を返すことが期待されます。

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

InboxのURLはHTTPのLinkヘッダーまたはリソース本体で、rel値がhttp://www.w3.org/ns/ldp#constrainedByの形で、独自の制約（例：SHACL、Web Annotation Protocolなど）を告知できます。送信者は制約仕様に従うべきであり、従わない場合は受信者が通知を拒否して適切な4xxエラーコードを返すことがあります。

Inbox（ターゲット）を告知するリソースの発行者は、信頼できるサーバー上で公開すべきです。発行者は、サードパーティがヘッダーや内容にアクセスできると通知がリダイレクトされる場合があることに注意する必要があります。

この仕様は、消費者が受信者から通知をプルで読み取る方法を記述しますが、消費者が新しい通知やInbox内容の更新をプッシュで受け取れるよう要求したい場合もあります。同様に、受信者が特定の送信者からの通知を自らリクエストしたい場合もあるでしょう。このようなサブスクリプション機構は範囲外ですが、送信者・受信者・消費者がそのような連携を独自に設定することは妨げられません。購読を有効にしたい実装は、ActivityPub、WebSub、WebSocket プロトコル、HTTP Web Pushなど既存の仕組みを利用できます。

Activity Streams 2.0 Core 対応を目指す受信者実装者は、Content-Typeや語彙の等価性に関する情報として Social Web Protocols - Inbox Interop を参照できます。

分散ネットワークにおいて国際的なユーザーベースを築くことは重要です。いくつかのLDNインタラクションは、HTML断片や要約項目など自然言語テキストを持つ内容を返す場合がありますが、すべてに対して多言語表現を用意するのが常に可能とは限りません。実装には、利用可能な言語の探索や言語交渉の手段（HTTPのAccept-Languageヘッダーによるリクエストごとの最適な言語選択など）を提供することが推奨されます。

受信者が送信者または消費者に認証を期待する場合は、他のデータ（他のエラーコードを含みます）を返す前に資格情報の有効性を必ずチェックすべきです。たとえば、認証されていない要求者に対してInboxの存在確認を先に行い404 Not Foundを返すべきではありません。

トークンパス方式による認証はHTTPS経由で行う必要があります。

以下の設問は、Self-Review Questionnaire: Security and Privacy のガイドラインに基づき、この仕様のセキュリティやプライバシーの検討点を確認するものです。

この仕様は個人識別可能な情報（PII）を扱いますか？

通知ペイロードには送信者や受信者を識別する情報など、あらゆるデータが含まれる可能性があります。通知データへのアクセス管理は受信者側で制御されます。機微な情報を送信する場合、受信者側がInboxの内容の公開読み出しを許可するアクセス制御を行う場合があることに注意すべきです。

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

（上述の）通知ペイロード内の個人識別情報と同様の影響があります。

この仕様はオリジンに新たにブラウザセッションをまたいで残る新しい状態を導入しますか？

いいえ。

この仕様はWeb上で永続的かつクロスオリジンな状態を公開しますか？

いいえ。

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

いいえ。

この仕様は新しいスクリプト実行/ローディング機構を導入しますか？

いいえ。

この仕様はオリジンにユーザーの位置情報へのアクセスを認めますか？

いいえ。

この仕様はオリジンにユーザー端末のセンサーへのアクセスを認めますか？

いいえ。

この仕様はオリジンにユーザー端末ローカル環境の側面へのアクセスを認めますか？

いいえ。

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

いいえ。

この仕様はオリジンにユーザーエージェントのネイティブUIの何らかの制御を許可しますか？

いいえ。

この仕様はWeb上に一時的な識別子を公開しますか？

いいえ。

この仕様はファーストパーティ／サードパーティ文脈ごとに挙動を区別しますか？

いいえ。

この仕様はユーザーエージェントの「シークレット」モードでどのように動作すべきですか？

Webサイトがユーザーが「シークレット」モードであることを判断できないように動作します。

この仕様はユーザー端末にデータの永続化を行いますか？

いいえ。

この仕様には「セキュリティ考慮事項」「プライバシー考慮事項」セクションがありますか？

:)

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

いいえ。

• 例中の構文エラー修正
• Social Web Group Charterへの「in reply to」リンク追加
• 仕様の過去バージョンへのリンク追加
• 参考文献の更新

• 謝辞の更新

• 謝辞追加
• 通知の暗黙の応答コードやリクエストURIに関する説明を明確化
• 参考文献の更新

• Considerations配下に「自然言語コンテンツ」セクション追加
• PubSubへの参照修正
• 実装レポートとテストスイートにURL追加
• SVGに凡例追加
• AS2 bib fragment修正
• payload verificationの表現修正
• 「認証付きInbox」セキュリティガイダンスを追加

• 例の追加と更新
• HTTP HEAD/GETによる検出表現の改善
• 編集面の修正（文法・言い換え）
• Accept-Post参照修正、OPTIONSでの出現について明示
• 国際化レビューのフィードバック（例）統合

• 誤字、リンク修正
• セクション順序をSending, Receiving, Consumingに変更
• 例の更新
• RFC7231の参照追加
• URI検出の表現明確化
• Considerations配下の非規範セクションにサブ見出し追加
• 全体概要図追加
• 「Considerations」配下にRetry Discoveryの非規範サブセクション追加
• 検出について丁寧さに言及
• Preventing Abuseを各規範セクションへ移動
• Sender VerificationをReceiving配下へ移動
• ActivitStreams 2.0 SupportをConsiderationsへ移動
• Payload VerificationをConsumingのNoteに移動
• 規範・一部非規範記述をConsiderationsから前方セクションへ移動
• 「セキュリティ・プライバシーレビュー」セクション追加
• はじめにの更新

• 誤字・句読点・命名修正
• 出口基準の追加
• Acceptヘッダー利用時・省略時の挙動を明確化
• Linkヘッダーフィールドのrelation主語に関するノート追加
• GETによるLinkヘッダーの検出追加、リンク主語URI（そのInbox用）をターゲットURLで明確化
• 要約の表現改訂
• Target Ownershipに関する考察追加
• 「どのリソースもInboxを持つことができる」に言及
• 通知の購読セクション追加

• 例の改善（例の追加・更新・構文修正、@contextのhttps化）
• 誤字・句読点・命名の修正
• payload記述におけるnon-normativeな配慮記述を反映