4.
モデル
アクティビティ語彙 は、Activity Streams
2.0のコアオブジェクトタイプとプロパティを規範的に定義しています。
この語彙で定義されるオブジェクトタイプは、8つのコアタイプのセットと、多くのソーシャルWebアプリケーションで共通して使われるActivityおよびObjectの拡張セットに分割されています。コアタイプには以下が含まれます：
Activity Streams 2.0 ドキュメント内のすべてのJSONオブジェクトは、
Object Link
Activity Streams 2.0 ドキュメントのJSONオブジェクトは、
(a) type プロパティの値として"Link"を含む場合、または(b) type プロパティ値に含まれる型のいずれかが Link の拡張であると定義されている場合（例: Mention 参照）、それは
Link Object
4.1 Object
Object
全ての Object 型はグローバル識別子（id プロパティで絶対IRIとして示す）および"オブジェクト型"（type
プロパティで示す）に加え、アクティビティ語彙 で規範的に定義される共通のプロパティ群を持ちます。これには次が含まれます：
attachment attributedTo audience content context contentMap name nameMap endTime generator icon image inReplyTo location preview published replies startTime summary summaryMap tag updated url to bto cc bcc mediaType duration
全てのプロパティは任意です（idとtypeも含む）。
図 7
以下は、グローバル識別子とオブジェクト型を表すために id および type プロパティを使用したObjectの例です：
例7
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"id" : "http://example.org/foo" ,
"type" : "Note" ,
"name" : "My favourite stew recipe" ,
"attributedTo" : {
"id" : "http://joe.website.example/" ,
"type" : "Person" ,
"name" : "Joe Smith"
},
"published" : "2014-08-21T12:34:56Z"
}
アクティビティ語彙 では、多くのソーシャルWebアプリケーションで共通して使用される
Object 型が定義されています。本仕様は、これらオブジェクトの意味論的に特定なプロパティまでは定義しません。Activity
Vocabularyでカバーされない詳細な情報は外部語彙を用いて表現できます。
また、実装はActivity
Vocabularyで定義されていない新しい型のObjectを導入することができますが、他の実装で認識されない拡張型に過度に依存すると互換性の問題が発生する可能性があります。既存Object型との無用な重複やオーバーラップを避けるよう留意してください。
拡張型がコア語彙型と重複する場合、実装は必ず コア語彙型も指定しなければなりません。たとえば、いくつかの語彙（例：The Good
Relations Vocabulary）は独自の場所型を定義しています。たとえば
http://purl.org/goodrelations/v1#Location 必ず
Place
図 8
Place と gr:Location の両方であるObjectの例：
例8
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{
"gr" : "http://purl.org/goodrelations/v1#"
}
],
"type" : ["Place" , "gr:Location" ],
"name" : "Sally's Restaurant" ,
"longitude" : 12.34 ,
"latitude" : 56.78 ,
"gr:category" : "restaurants/french_restaurants"
}
一部の外部語彙で定義されたプロパティは、Activity Vocabularyで定義されたものと重複・重ね合うことがあります。その場合、相互運用性確保のため、実装はActivity Vocabulary定義のプロパティを優先 して使う必要があります。
4.1.1 Object型のテキスト表現
Activity Streamsの利用者は、Webブラウザやコンソールインタフェースでの表示など、Activity Streamsオブジェクトのテキスト表現を必要とする場合がよくあります。
name
summary name
プロパティがない場合、summary プロパティにはマークアップを含めるべきではなく、テキスト表現として適切な短さであるべきです。
図 9
著者が定義したnameを持つノートの例
例9
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"id" : "http://example.org/note/123" ,
"name" : "Our Weather Is Fine" ,
"content" : "I feel that the weather is appropriate to our season and location."
}
図 10
自動生成されたsummaryを持つノートの例
例10
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"id" : "http://example.org/note/124" ,
"summary" : "A note by Sally" ,
"content" : "Everything is OK here."
}
name と summary
はどちらも存在しないことがあり、エンドユーザーの現在の言語に明示的な値がない場合や、テキスト表現としては長すぎる場合もあります。これらの場合、利用側の実装ではフォールバック戦略を持つべきです。
4.2
Link
Link は他リソースへの間接参照であり、その概念的なモデルは [RFC5988 height や width は参照された画像の実際のピクセル数ではなく、表示時の希望サイズを示す場合があります。
Linkの対象URIは必須のhref Link インスタンスはアクティビティ語彙 で規範的に定義される次の任意プロパティ群を共有します：
id name hreflang mediaType rel height width
例えば、全ての Object は
image
図 11 追加メタデータなしで1枚の画像を参照したい場合は、絶対IRIのJSON文字列として直接関連付けできます。
例11
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Application" ,
"id" : "http://example.org/application/123" ,
"name" : "Exampletron 3000" ,
"image" : "http://example.org/application/123.png"
}
図 12
一方、参照リソースのMIMEタイプなど追加メタデータが必要な場合は、Link を使用できます：
例12
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Application" ,
"id" : "http://example.org/application/123" ,
"name" : "Exampletron 3000" ,
"image" : {
"type" : "Link" ,
"href" : "http://example.org/application/123.png" ,
"mediaType" : "image/png"
}
}
前者の例は画像リソースとの非修飾な直接関係を確立し、後者の例は追加プロパティを指定することができる修飾付きの間接関係 を作ります。
図 13
複数値を表現したい場合は、文字列と Link
を混在させたJSON配列が利用可能です：
例13
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Application" ,
"id" : "http://example.org/application/123" ,
"name" : "Exampletron 3000" ,
"image" : [
"http://example.org/application/abc.gif" ,
{
"type" : "Link" ,
"href" : "http://example.org/application/123.png" ,
"mediaType" : "image/png"
}
]
}
このような配列内の個々の項目は互いに独立しており、順序に意味はありません。
RFC 5988では、全てのリンクにはコンテキストを表現する「リンクリレーション」があるとしています。Link 内では、
rel relがなければ未指定扱いとなります。1つのLinkに複数のリレーション値を与えることもできます。JSONシリアライズでは単一の場合はJSON文字列、複数の場合は文字列の配列で指定します。
リンクリレーションのスコープは、そのLink が直下にあるオブジェクトです。
次の例では2つの参照があり、1つ目はリレーション未指定、2つ目が "thumbnail" になっています。
図 14
例14
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Application" ,
"id" : "http://example.org/application/123" ,
"name" : "Exampletron 3000" ,
"image" : [
"http://example.org/application/abc.gif" ,
{
"type" : "Link" ,
"href" : "http://example.org/application/123.png" ,
"mediaType" : "image/png" ,
"rel" : "thumbnail"
}
]
}
[HTML5 RFC5988 RFC5988 HTML5 すべきです 。未登録値の使用も可能 です。
Link 型とObject 型は互いに交わりません。すなわち、1つのObject が同時にLink になることはありません。
4.3 アクター
アクターオブジェクトは、アクティビティを実行できるエンティティを表す基本型Object の特殊化です。アクティビティ語彙 は、5種類のアクター型を規範的に定義しています：
Application
Group Organization Person Service
本仕様はアクターを非常に一般的な方法でのみ定義し、それぞれに意味的に特定なプロパティは定義しません。全てのアクターオブジェクトはObject の特殊化であり、全Object共通のコアプロパティを継承します。アクティビティ語彙でカバーされない追加情報は外部の語彙で表現可能です。VCard
[
vcard-rdf Person 、
Group 、Organization
インスタンスへの追加メタデータ提供に推奨 されます。
図 15 VCardプロパティを拡張したPersonアクターを持つアクティビティの例：
例15
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{"vcard" : "http://www.w3.org/2006/vcard/ns#" }
],
"summary" : "Sally created a note" ,
"type" : "Create" ,
"actor" : {
"type" : ["Person" , "vcard:Individual" ],
"id" : "http://sally.example.org" ,
"name" : "Sally Smith" ,
"vcard:given-name" : "Sally" ,
"vcard:family-name" : "Smith"
},
"object" : {
"type" : "Note" ,
"content" : "This is a simple note"
}
}
実装はアクティビティ語彙で定義されていない新しいアクター型を導入できますが、他の実装で認識されない拡張型に頼りすぎると相互運用性の問題が生じます。既存アクター型との重複や過剰なオーバーラップは避けるべきです。
拡張型がコア語彙型と重複する場合、実装は必ず コア語彙型も指定しなければなりません。例えば一部の語彙（例：VCard）は人物表現用の独自型を定義しています。たとえばvcard:Individualをアクターとして用いる場合、必ず
Person
4.4 アクティビティ
アクティビティオブジェクトは、すでに発生した、進行中、または将来発生する可能性のあるアクションに関する情報を提供する基本型Object の特殊化です。
全Object インスタンスが持つ共通プロパティに加え、Activityオブジェクトは
語彙 で定義された次の追加プロパティをサポートします：
actor object target origin result instrument
typeプロパティは、そのアクティビティステートメントが表現するアクションの種類を識別するために使用されます。
図 16 次の例は単純なアクティビティを示します：
例16
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Joe liked a note" ,
"type" : "Like" ,
"id" : "http://www.test.example/activity/1" ,
"actor" : "http://example.org/profiles/joe" ,
"object" : "http://example.com/notes/1" ,
"published" : "2014-09-30T12:34:56Z"
}
アクティビティ語彙 は、多くのソーシャルWebアプリケーションで共通して使われる少数のActivity型を定義しています。本仕様はこれらアクティビティの意味的に特定なプロパティまでは定義しません。アクティビティ語彙でカバーされない詳細な情報は外部語彙で表現可能です。
実装はアクティビティ語彙で定義されていない新しいアクティビティ型を導入できますが、他実装で認識されない拡張型に頼りすぎると相互運用性の問題が生じます。既存アクティビティ型との重複や過剰なオーバーラップは避けるべきです。
拡張型がコア語彙型と重複する場合、実装は必ず コア語彙型も指定しなければなりません。例えば一部語彙（例：Schema.org）はアクション表現の独自型を定義しています。たとえばhttp://schema.org/LikeAction 必ず
Like
図 17
Like http://schema.org/LikeAction の両方であるアクティビティ例：
例17
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Joe liked a note" ,
"type" : ["Like" , "http://schema.org/LikeAction" ],
"id" : "http://www.test.example/activity/1" ,
"actor" : "http://example.org/profiles/joe" ,
"object" : "http://example.com/notes/1" ,
"published" : "2014-09-30T12:34:56Z"
}
実装はアクティビティオブジェクトを受動的にも命令的にも利用できます。受動的な意味では、アクティビティはすでに発生したまたは発生中の行動を記録するものです。命令的な意味では、アクティビティはアプリケーションに対して状態をアクション内容に沿って変更するよう指示するコマンドの役割も担えます。ただし、本仕様はフォーマットの利用方法を制約する規範的な処理モデルを定義しないため、アクティビティステートメントを通知とみなすか命令とみなすかは実装ごとに異なる場合があります。
4.5 自動詞アクティビティ
自動詞アクティビティ（IntransitiveActivity）オブジェクトは、アクティビティ 型の特殊化で、自動詞的なアクションを表現します。自動詞アクティビティオブジェクトは
object
4.6 コレクション
Collectionオブジェクトは、他の
Object Link
のコンテナとして機能する基本型Objectの特殊化です。
全ての
Object Collection
items |
totalItems |
first |
last |
current
Collection OrderedCollection 利用できます 。JSONシリアライズでは、順序なし項目はitemsプロパティ、順序あり項目はorderedItemsプロパティで表します。
図 18
以下はシンプルな順序なしコレクションです：
例18
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Object history" ,
"type" : "Collection" ,
"totalItems" : 2 ,
"items" : [
{
"type" : "Create" ,
"actor" : "http://www.test.example/sally" ,
"object" : "http://example.org/foo"
},
{
"type" : "Like" ,
"actor" : "http://www.test.example/joe" ,
"object" : "http://example.org/foo"
}
]
}
図 19
以下はシンプルな順序付きコレクションです：
例19
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Object history" ,
"type" : "OrderedCollection" ,
"totalItems" : 2 ,
"orderedItems" : [
{
"type" : "Create" ,
"actor" : "http://www.test.example/sally" ,
"object" : "http://example.org/foo"
},
{
"type" : "Like" ,
"actor" : "http://www.test.example/joe" ,
"object" : "http://example.org/foo"
}
]
}
4.6.1 コレクションページング
コレクションは大量の項目を含むことができます。多くの場合、items（またはorderedItems）プロパティのみですべての項目をシリアライズするのは非現実的です。そのような場合、コレクション内の項目を明確なサブセットまたは「ページ」に分割できます。ページは
CollectionPage
CollectionPageCollection
partOf |
next |
prev |
partOfプロパティは、そのCollectionPageが属する
Collection
first、next、prev、last、currentプロパティは、親コレクション内の項目の追加サブセットを含む他の
CollectionPage
Collectionオブジェクトと同様に、CollectionPage内の項目も順序付きでも順序なしでもかまいません。OrderedCollectionPage 利用できます 。
OrderedCollectionPageCollectionPageOrderedCollectionOrderedCollectionPageはページに含まれる最初の項目の相対インデックス位置を示すstartIndex
図 20
Collection、OrderedCollection、CollectionPage、OrderedCollectionPage間の関係図：
順序付きか否かに関わらず、コレクションのページは通常シーケンス（単方向または双方向リンクリスト）で並びます。firstプロパティはこの順序の最初のページ、lastは最後のページ、prevとnextはそれぞれ直前・直後のページを識別します。
図 21
コレクションページングモデルの図示：
currentプロパティは、Collection内で最近作成または更新された項目のサブセットを含むページを識別します。
first、last、next、prev、currentプロパティの値は、単一の
CollectionPageLink
図 22
以下はページング付きのシンプルな順序なしコレクションです：
例20
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Sally's recent activities" ,
"type" : "Collection" ,
"id" : "http://example.org/foo" ,
"totalItems" : 10 ,
"first" : {
"type" : "CollectionPage" ,
"id" : "http://example.org/foo?page=1" ,
"partOf" : "http://example.org/foo" ,
"next" : "http://example.org/foo?page=2" ,
"items" : [
{
"type" : "Create" ,
"actor" : "http://www.test.example/sally" ,
"object" : "http://example.org/foo"
}
]
}
}
OrderedCollectionでページングを使用する場合、実装がページの順序を必ずしも予測可能な順で処理する保証がないため、注意が必要です。論理コレクション内の全メンバー項目を正しく並び替えたい場合、まずシーケンスの最初（または最後）のページに移動し、next（またはprev）リンクを再帰的にたどって全ページを処理します。OrderedCollectionのページはOrderedCollectionPageのインスタンスであるべきです 。もしそうでない場合、利用側は項目の正しい順序を復元する手段を持ちません。
4.7 自然言語値
語彙 で定義されているいくつかのプロパティは、「自然言語値」を持つものとして定義されています。これらは一つ以上の言語を用いる人間が読める文字列です。JSONシリアライズでは、(1)単一のJSON文字列、または(2)整形式な
[BCP47 name" は
name nameMap" はオブジェクト形式を表します。
図 23 言語情報なしの単一name文字列値：
例21
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Object" ,
"name" : "This is the title"
}
図 24 複数の言語別値：
例22
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Object" ,
"nameMap" : {
"en" : "This is the title" ,
"fr" : "C'est le titre" ,
"es" : "Este es el título"
}
}
オブジェクト形式でのすべてのキーは 必ず 整形式な [BCP47 必ず 文字列でなければなりません。
アクティビティ語彙 は、自然言語値を使用する3つのプロパティを定義しています：
name summary content name"、"summary"、"content"
が文字列形式、"nameMap"、"summaryMap"、"contentMap" がオブジェクト形式を表します。
特別な言語タグ "und" は、その値の言語が不明または未決定であることを明示したい場合にオブジェクト形式で利用できます。
図 25 "und" 言語タグの使用：
例23
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Object" ,
"nameMap" : {
"und" : "This is the title"
}
}
4.7.1 デフォルト言語コンテキスト
[JSON-LD @context内で @language プロパティを使ってデフォルト言語を識別することができます 。この仕組みは、JSON-LDとしてのActivity Streams
2.0ドキュメントの処理を選択しない実装では理解されない場合があります。
図 26
JSON-LD @context内でデフォルトの"@language"を指定：
例24
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{
"@language" : "en"
}],
"type" : "Object" ,
"name" : "This is the title"
}
4.7.2 双方向テキスト
Activity Streams 2.0ドキュメント内の自然言語値は、双方向テキストを含む場合があります 。Activity
Streams 2.0 ドキュメント全体の基本方向はデフォルトで左から右です。個々の自然言語値の基本方向は、以下の方法で変更できます 。
自然言語値に双方向テキストを指定する際、テキストの最初の強い方向性文字で基準方向が正確に同定できない場合、発行者は適切なUnicode双方向制御文字で値の先頭を明示的に指定するか、許可されている場合はHTML方向マークアップを利用するべきです 。
双方向テキストを含むActivity Streams
2.0ドキュメントの利用者は、マークアップタグ外の最初の強い方向性文字をスキャンする、または方向マークアップがあればそれを利用するなどして、任意の自然言語値の基本方向を判別すべき です。基準方向が特定されたら、利用者はUnicode双方向アルゴリズム [BIDI を行います 。そのために、基準方向を適用するために表示前に追加で制御文字やマークアップで文字列を囲む必要がある場合もあります。
プロパティ
値
方向
方法
name"פעילות הבינאום, W3C "右から左
最初の強い方向性文字
name
"The document was titled, '\u2067פעילות הבינאום, W3C \u2069'"
左から右
最初の強い方向性文字
name"\u200FHTML היא שפת סימון"右から左
双方向制御文字
name"\u200E'سلام' is hello in Persian."左から右
双方向制御文字
summary
<p dir="rtl">HTML היא שפת סימון>/p>
右から左
HTMLマークアップ
summary<p>פעילות הבינאום, W3C </p>
右から左
マークアップを無視した最初の強い方向性文字
summary
<p title="سلام">Hello</p>
左から右
マークアップを無視した最初の強い方向性文字
4.8 言語のマークアップ
既知の場合、Activity Streams 2.0 の発行者は 明示的に 自然言語プロパティの言語をマークアップすべきです。マッププロパティ、またはデフォルト言語タグを使うことができます。
注 : 例
本仕様の例のすべてが自然言語プロパティの言語を明示的にマークしているわけではありません。これは意図的なものです。著者およびワーキンググループは、実装者が明示的な言語タグ付きの例をそのまま新しいドキュメントのテンプレートとしてコピー&ペーストし、不正確な言語マークアップになることを避けたいためです。
5. 拡張性
Activity Streams 2.0 では、「拡張」とは アクティビティ語彙
で定義されていないプロパティ、アクティビティ、アクター、またはオブジェクト型すべてを指します。未知の拡張を見つけた場合でも、受信側実装は 処理を中断したりエラーを出したりしてはなりません 。それらのプロパティが存在しないかのように、処理を継続しなければなりません 。拡張のサポート状況は実装ごとに異なり、拡張に関する規範的な処理モデルは存在しません。そのため、拡張への過度な依存は、他実装との相互運用性低下を招く場合があります。
拡張の定義や曖昧性排除の主要な仕組みとして [JSON-LD JSON-LD 利用すべきです 。
Activity Streams 2.0 の名前空間文書にはいくつかメジャーな拡張も含まれており、https://www.w3.org/ns/activitystreams#extensions
で確認できます。Social Web Incubator Community Group も Activity Streams extensions
についてのWikiを運営しています。
JSON-LD Processing Algorithms [
JSON-LD-API すべきです 。
また、JSON-LD ドキュメント内で使用できない正当な JSON 構造体が存在することにも注意が必要です。たとえば、GeoJSON
仕様などで用いられる「配列の配列」は JSON-LD では禁じられています。このような構造は Activity Streams 2.0 ドキュメントの拡張として自由に使えますが、標準の JSON-LD
Processing Algorithms を利用する実装は、そうした拡張を無視するか、JSON-LD アルゴリズム適用前に互換可能な構造へマッピングしなければなりません。単純なGeoJSONのポイントは
Place GeoSparql の Well-Known
Text へ変換可能です（非規範的な例を下記に示します）。
図 27 GeoJSON ポイント座標：
例25
{
"type" : "Point" ,
"coordinates" : [36.74 , -119.77 ]
}
図 28 等価な Place への変換例：
例26
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"name" : "Fresno, California" ,
"type" : "Place" ,
"latitude" : 36.74 ,
"longitude" : -119.77
}
図 29 GeoJSON ポリゴン座標：
例27
{
"type" : "Polygon" ,
"coordinates" : [
[
[100.0 , 0.0 ],
[101.0 , 0.0 ],
[101.0 , 1.0 ],
[100.0 , 1.0 ],
[100.0 , 0.0 ]
]
]
}
図 30 等価な GeoSparql Well-Known-Text 例：
例28
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{"gsp" : "http://www.opengis.net/ont/geosparql" }
],
"summary" : "A polygon" ,
"type" : "gsp:Geometry" ,
"gsp:asWKT" : "Polygon((100.0, 0.0, 101.0, 0.0, 101.0, 1.0, 100.0, 1.0, 100.0, 0.0))"
}
5.1 コンパクトURIのサポート
JSON-LD構文は「コンパクトURI」の利用をサポートしています。コンパクトURIとは、定義されたプレフィックスを利用しシリアライズを簡素化するためのURIの別形式です。例えば、URI
http://example.org/term は ex:を http://example.org/ に割り当てれば
ex:term と表せます。
JSON-LD内でのコンパクトURIプレフィックス定義は @context 定義内に記述されます。例：
図 31 JSON-LDのコンパクトURI定義例
例29
{
"@context" : {
"ex" : "http://example.org/" ,
"term" : {
"@type" : "id" ,
"@id" : "ex:term"
}
},
"term" : "ex:Foo"
}
この例では、プロパティ名 term も値 ex:Foo もコンパクトURIです。プロパティ名 term は
http://example.org/term に、値
ex:Foo は http://example.org/Foo へ展開されます。
JSON-LDにおいて、値へのコンパクトURI展開は @context 定義内でプロパティが "type": "id"
と明示的に定義されている場合に適用されます。具体的には、IRI（またはURI）値が期待される場所でコンパクトURIを使うことができます。
Activity Streams 2.0 の実装で拡張を完全にサポートしたい場合は、JSON-LD仕様で定めるコンパクトURI展開を必ず サポートしなければなりません。展開はすべてのプロパティ名および、JSON-LD @context で型 @id
と定義されたすべてのプロパティ値に適用されます。
コンパクトURI形式への過度の依存は不明確さや実装間の相互運用性問題につながる恐れがあります。そのため、コンパクトURIはプロパティ名やtypeプロパティ値「以外」では極力避けるべきです 。
5.2 拡張の再シリアライズ
JSON-LDを利用して拡張プロパティを含むActivity Streams
2.0ドキュメントをパース・再シリアライズする場合、実装は拡張プロパティが元のドキュメント内で保存・適切にシリアライズされるよう十分に注意 すべきです。
例えば次のように、仮の foo および bar 拡張プロパティを含むActivity
Streamオブジェクトを考えます。foo拡張はJSON-LD @context で定義され、bar はされていません。
図 32 単純な拡張Object例
例30
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{"foo" : "http://example.org/foo" }
],
"type" : "Note" ,
"content" : "This is a simple note" ,
"foo" : 123 ,
"bar" : 321
}
このNoteオブジェクトを受信した実装は、普通のJSONオブジェクトとしてパースすることも、標準のJSON-LD拡張アルゴリズムを使うこともできます。
通常のJSONとしてパースし再シリアライズする場合（例えば保存や再配布）、@context、foo、bar
の各プロパティ値をそのまま保持すればOKです。
ただしJSON-LD拡張アルゴリズムを利用した場合、@context は展開結果から消え、bar プロパティは「ブランクノード」
_:bar にマッピングされます。その後、規範的なActivity Streams 2.0
contextで再シリアライズすると、JSON-LDのコンパクト化結果は以下のようになります：
図 33 再シリアライズされたコンパクト形式：
例31
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"content" : "This is a simple note" ,
"http://example.org/foo" : 123 ,
"bar" : 321
}
これはほぼ元と同じですが、foo
プロパティのラベルが完全に展開されたURIになってしまうのは理想的ではありません。受信文書のJSON-LD展開処理を行った場合、正しく再シリアライズできるように、実装は展開時の
@context を保持し、それをJSON-LDコンパクト化の際に再利用 すべきです 。
A. 謝辞
Activity Streams 2.0仕様は W3C
ソーシャルウェブワーキンググループの成果です。編集者は議論、課題、テストなどを通じて本仕様の形成に貢献してくださったワーキンググループの全メンバーに感謝します。
また、仕様が W3C ソーシャルウェブワーキンググループに寄稿される以前に Activity Streams
に貢献してくださったすべての方々にも編集者一同御礼申し上げます。Activity Streams
1.0はコミュニティ主導の取り組みであり、この仕様もそれ以前の貢献がなければ今の形には至りませんでした。特に次の方々（敬称略、順不同）をはじめ、数多くのコミュニティの皆様の貢献に感謝します。Abdul Qabiz,
Adina Levin, Adrian Chan, Adriana Javier, Alan Hoffman, Alex Kessinger, Alexander Ovchinnikov, Alexander
Zhuravlev, Alexandre Loureiro Solleiro, Amy Walgenbach, Andres Vidal, Angel Robert Marquez, Ari Steinberg,
Arjan Scherpenisse, Arne Roomann-Kurrik, Beau Lebens, Ben Hedrington, Ben Metcalfe, Ben Werdmuller, Benjamin
Goering, Bill de hOra, Bo Xing, Bob Aman, Bob Wyman, Brett Slatkin, Brian Walsh, Brynn Evans, Charlie
Cauthen, Chris Chabot, Chris Messina, Chris Toomey, Christian Crumlish, Dan Brickley, Dan Scott, Daniel
Chapman, Danny Ayers, Dare Obasanjo, Darren Bounds, David Cramer, David Nelson, David Recordon, DeWitt
Clinton, Douglas Pearce, Ed Summers, Elias Bizannes, Elisabeth Norris, Eric Marcoullier, Eric Woods, Evan
Prodromou, Gee-Hsien Chuang, Greg Biggers, Gregory Foster, Henry Saputra, Hillary Madsen, Howard Liptzin,
Hung Tran, Ian Kennedy, Ian Mulvany, Ivan Pulleyn, Jacob Kim, James Falkner, James Pike, James Walker, Jason
Kahn, Jason Kantz, Jeff Kunins, Jeff Martin, Jian Lin, Johannes Ernst, John Panzer, Jon Lebkowsky, Jon Paul
Davies, Jonathan Coffman, Jonathan Dugan, Joseph Boyle, Joseph Holsten, Joseph Smarr, Josh Brewer, Jud
Valeski, Julien Chaumond, Julien Genestoux, Jyri Engestroem, Kaliya Hamlin, Kevin Marks, Laurent Eschenauer,
Laurie Voss, Leah Culver, Libby Miller, Manu Mukerji, Mark Weitzel, Marko Degenkolb, Marshall Kirkpatrick,
Martin Atkins, Martin Svensson, Marty Alchin, Mary Hoder, Matt Leventi, Matt Wilkinson, Matthias
Mueller-Prove, Max Engel, Max Wegmueller, Melvin Carvalho, Michael Buckbee, Michael Chan, Michael
Richardson, Michael Sullivan, Mike Macgirvin, Mislav Marohnić, Mo Jangda, Monica Wilkinson, Nate Benes,
NeilFred Picciotto, Nick Howard, Nick Lothian, Nissan Dookeran, Nitya Narasimhan, Pablo Martin, Padraic
Brady, Pat Cappelaere, Patrick Aljord, Peter Ferne, Peter Reiser, Peter Saint-Andre, Phil Wolff, Philip
(flip) Kromer, Richard Cunningham, Richard Zhao, Rick Severson, Robert Hall, Robert Langbert, Robert Dolin,
Robin Cover, Ryan Boyd, Sam Sethi, Scott Raymond, Scott Seely, Simon Grant, Simon Wistow, Stephen Garcia,
Stephen Sisk, Stephen Paul Weber, Steve Ivy, Steve Midgley, Steven Livingstone-Perez, Sylvain Carle, Sylvain
Hellegouarch, Tantek Çelik, Tatu Saloranta, Tim Moore, Timothy Young, Todd Barnard, Tosh Meston, Tyler
Gillies, Will Norris, Zach Copley, Laurent-Walter Goix, Matthew Marum, Andy Smith, and Zach Shepherd.
