4. 模型
Activity Vocabulary 规范性地定义了 Activity Streams 2.0 的核心对象类型与属性。
该词汇集定义的对象类型被细分为一组核心类型（共八个），以及一组在社交网络应用中通用的扩展活动与对象类型。核心类型包括：
Activity Streams 2.0 文档中的每个 JSON 对象要么是一个 Object Link
若满足以下任一条件，Activity Streams 2.0 文档中的 JSON 对象就是一个 Link type 属性，其值包含 “Link”；或 (b) type 属性值中包含的任何类型被定义为 Link 的扩展（例如参见 Mention ）；否则该 JSON 对象将被视为 Object
4.1 对象 (Object)
Object
除具有全局标识符（使用 id 属性表示为绝对 IRI）与“对象类型”（使用 type 属性表示）之外，Object 类型的所有实例都共享一组由 Activity Vocabulary 规范性定义的通用属性。这些属性包括：
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 属性来表达全局标识符与对象类型：
示例 7
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"id" : "http://example.org/foo" ,
"type" : "Note" ,
"name" : "我最喜欢的炖菜食谱" ,
"attributedTo" : {
"id" : "http://joe.website.example/" ,
"type" : "Person" ,
"name" : "Joe Smith"
},
"published" : "2014-08-21T12:34:56Z"
}
Activity Vocabulary 定义了一系列许多社交网络应用通用的 Object 类型。本规范并未针对这些对象中的大多数对象定义特定语义的属性。可以使用外部词汇集来表达 Activity Vocabulary 未涵盖的额外细节。
此外，虽然实现可以自由引入 Activity Vocabulary 定义之外的新对象类型，但当应用过度依赖其它实现无法识别的扩展类型时，可能会出现互操作问题。应注意不要与现有对象类型不当重叠或重复。
当一个实现使用了与核心词汇集类型重叠的扩展类型时，该实现必须 同时指定该核心词汇集类型。例如，某些词汇集（如 Good Relations Vocabulary）定义了其自有的用于描述地点的类型。若实现希望将 http://purl.org/goodrelations/v1#Location 必须 同时将该对象标识为 地点 (Place)
图例 8 同时为 Place 与 gr:Location 的对象：
示例 8
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{
"gr" : "http://purl.org/goodrelations/v1#"
}
],
"type" : ["Place" , "gr:Location" ],
"name" : "Sally 的餐馆" ,
"longitude" : 12.34 ,
"latitude" : 56.78 ,
"gr:category" : "restaurants/french_restaurants"
}
某些由外部词汇集定义的属性可能与 Activity Vocabulary 定义的属性重叠或重复。为了保持一致的互操作性，在存在此类重叠的地方，实现必须 优先使用 Activity Vocabulary 定义的属性。
4.1.1 对象类型的文本表示
Activity Streams 消费者通常需要 Activity Streams 对象的文本表示，例如用于在 Web 浏览器或控制台界面中显示。
name 应该 从创建者或其它用户的输入中派生。
summary 应该 用作备选的文本表示，且可能由发布者自动生成。若不含 name 属性，则 summary 属性不该 包含标记语言，且应该 足够简短，以便用作对象的合理文本表示。
图例 9
由作者定义 name 的贴文
示例 9
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"id" : "http://example.org/note/123" ,
"name" : "我们这天气不错" ,
"content" : "我觉得天气很适合我们这的季节和地点。"
}
图例 10
带有自动生成的 summary 的贴文
示例 10
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"id" : "http://example.org/note/124" ,
"summary" : "Sally 的贴文" ,
"content" : "这里一切都好。"
}
name 与 summary 可以 缺失，可以 缺少最终用户当前语言的显式值，并且其长度可以 超过在当前语言语境下用作文本表示的合适长度。在这种情况下，消费端实现应该 具有回退对象的文本表示的能力。
4.2 链接 (Link)
Link 描述了对另一个资源的有限定的、间接的引用，这与 [RFC5988 height 与 width 可能表示被引用图像所需的渲染大小，而不是被引用图像的实际像素尺寸。
Link 的目标 URI 使用必需的 href Link 实例共享以下由 Activity Vocabulary 规范性定义的通用可选属性：
id name hreflang mediaType rel height width
例如，所有对象 都可以包含一个 image
图例 11 要在没有任何额外元数据的情况下引用单个图像，可以直接关联表达为一个包含绝对 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 都有一个描述链接语境用途的 “链接关系 (link relation)”。在 Link 中，rel rel 属性，则认为链接关系是未指定的。任何给定的 Link 都可以有多个链接关系值。在 JSON 序列化中，单个链接关系表达为单个 JSON 字符串。多个链接关系表达为 JSON 字符串数组。
链接关系的范围是将该 Link 作为直接子项的对象。
以下示例提供了两个单独的引用。第一个的链接关系未指定，而第二个的链接关系为 “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 类型是彼此互斥的。也就是说，任何给定的 Object 都不能同时为一个 Link 。
4.3 行为体 (Actor)
Actor 对象是基础 Object 类型的特化，表示能够执行 Activity 的实体。Activity Vocabulary 规范性地定义了五种特定类型的 Actor：
Application (应用)
Group (群组)Organization (组织)Person (人)Service (服务)
本规范有意仅以最通用的方式定义 Actor，不对每种类型定义特定语义的属性。所有 Actor 对象都是 Object Person 、Group 与 Organization 实例，应该 使用 VCard [vcard-rdf
图例 15 带有使用 VCard 属性扩展的 Person 行为体的 Activity：
示例 15
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{"vcard" : "http://www.w3.org/2006/vcard/ns#" }
],
"summary" : "Sally 创建了一条贴文" ,
"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" : "这是一条简单的贴文"
}
}
虽然实现可以自由引入 Activity Vocabulary 定义之外的新 Actor 类型，但当应用过度依赖其它实现无法识别的扩展类型时，可能会出现互操作性问题。应注意不要过度重叠或重复现有的 Actor 类型。
当一个实现使用了与核心词汇集类型重叠的扩展类型时，该实现必须 同时指定该核心词汇集类型。例如，某些词汇集（如 VCard）定义了其自有的用于描述人的类型。若实现希望将 vcard:Individual 用作 Actor，必须 同时将该 Actor 标识为 Person
4.4 活动 (Activity)
Activity 对象是基础 Object 类型的特化，提供有关已发生、正在发生或将来可能发生的动作的信息。
除所有 Object 实例支持的通用属性外，Activity 对象还支持由 Vocabulary 定义的以下额外属性：
actor object target origin result instrument
type 属性用于标识活动语句所代表的动作类型。
图例 16 以下示例展示了一个简单的 Activity：
示例 16
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Joe 点赞了一条贴文" ,
"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"
}
Activity Vocabulary 定义了少量许多社交网络应用通用的 Activity 类型。本规范未针对这些活动中的大多数定义特定语义的属性。可以使用外部词汇集来表达 Activity Vocabulary 未涵盖的额外细节。
虽然实现可以自由引入 Activity Vocabulary 定义之外的新活动类型，但当应用过度依赖其它实现无法识别的扩展类型时，可能会出现互操作性问题。应注意不要过度重叠或重复现有的活动类型。
当一个实现使用了与核心词汇集类型重叠的扩展类型时，该实现必须 同时指定该核心词汇集类型。例如，某些词汇集（如 Schema.org）定义了其自有的用于描述动作的类型。若实现希望将 http://schema.org/LikeAction 必须 同时将该对象标识为 Like
图例 17 同时为 Like http://schema.org/LikeAction 的 Activity：
示例 17
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Joe 点赞了一条贴文" ,
"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"
}
实现可以自由地在被动操作与主动操作中使用 Activity 对象。在被动意义上，Activity 用于记录一个活动已经发生或正在发生。在主动意义上，Activity 可以用作一种命令形式，指示应用以某种与所描述动作一致的方式修改状态。然而，由于本规范并未定义约束应用如何使用该格式的规范性处理模型，因此关于活动语句是被解释为被动通知还是命令式命令的区别可能因实现而异。
4.5 不及物活动 (IntransitiveActivity)
IntransitiveActivity 对象是 Activity 类型的特化，表示不及物动作。IntransitiveActivity 对象没有 object
4.6 集合
Collection 对象是基础 Object Object 或 Link 的容器。
除由所有 对象 Collection
items |
totalItems |
first |
last |
current
Collection OrderedCollection 可以 用于标识其项始终有序的集合。在 JSON 序列化中，集合的无序项使用 items 属性表示，而有序项使用 orderedItems 属性表示。
图例 18
以下是一个简单的无序集合：
示例 18
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "对象历史" ,
"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" : "对象历史" ,
"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 OrderedCollection 中的相对索引位置。
图 20
Collection, OrderedCollection, CollectionPage, 与 OrderedCollectionPage 之间关系的说明：
无论是否有序，Collection 的页通常按序列排列（单向或双向链表）。first 属性用于标识该序列中的第一页，而 last 属性用于标识序列中的最后一页。prev 与 next 属性分别标识紧邻其前与紧邻其后的页。
图例 21
集合分页模型的可视化表示：
current 属性标识一个页，该页包含 Collection 中最近创建或更新的项子集。
first, last, next, prev, 与 current 属性的值可以是一个 CollectionPageCollectionPageLink
图例 22
以下是一个带分页的简单无序集合：
示例 20
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"summary" : "Sally 的最近活动" ,
"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 的实例。若 OrderedCollection 的页不是 OrderedCollectionPage 实例，则消费者将无法可靠地重新构建集合中项的适当顺序。
4.7 自然语言值
由 Vocabulary 定义的多个属性被定义为具有自然语言值。这些是使用一种或多种语言的、人类可读的字符串。在 JSON 序列化中，它们表达为：(1) 单个 JSON 字符串，或 (2) 一个 JSON 对象，将符合规范的 [BCP47 name” 标识 name nameMap” 表示对象形式。
图例 23 不带语言信息的单个 name 字符串值：
示例 21
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Object" ,
"name" : "这就是标题"
}
图例 24 多个特定语言的值：
示例 22
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Object" ,
"nameMap" : {
"zh" : "这是标题" ,
"fr" : "C'est le titre" ,
"es" : "Este es el título"
}
}
对象形式中的每个键必须 是一个符合规范的 [BCP47 必须 是字符串。
Activity Vocabulary 定义了三个使用自然语言值的属性：name summary content name”, “summary”, 与 “content” 代表 JSON 字符串形式；而术语 “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 @language 属性可以 在 @context 中使用以标识默认语言。选择不使用 JSON-LD 处理 Activity Streams 2.0 文档的实现可能无法理解此机制。
图例 26
在 JSON-LD @context 中指定默认 "@language"：
示例 24
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{
"@language" : "zh"
}],
"type" : "Object" ,
"name" : "这就是标题"
}
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 中，“扩展 (extension)”是指任何未由 Activity Vocabulary 定义的属性、活动、行为体或对象类型。消费端实现在遇到不熟悉的扩展时，不得 停止处理或报错，且必须 继续处理，将这些属性视同不存在。请注意，不同实现对扩展的支持可能有所不同，且本规范未定义扩展的规范性处理模型。因此，过度依赖扩展的实现可能会导致与其它实现之间的互操作性降低。
对于扩展，[JSON-LD 应该 使用 [JSON-LD
一些流行的扩展包含在 Activity Streams 2.0 命名空间文档中，可以在 https://www.w3.org/ns/activitystreams#extensions 查阅。社交网络孵化社区组 维护着一个关于 Activity Streams 扩展 的百科页面。
需要注意的是，目前定义的 JSON-LD 处理算法 [JSON-LD-API 应该 为所有扩展提供 @context 定义。
同样重要的是，有些有效的 JSON 构造无法在 JSON-LD 文档中使用。例如，JSON-LD 禁止使用“数组的数组”，而这在流行的 GeoJSON 规范中有所应用。虽然实现在 Activity Streams 2.0 文档中可以自由地将此类构造作为扩展使用，但使用标准 JSON-LD 处理算法的消费者在应用算法之前，需要忽略此类扩展或将其映射到替代的兼容构造。例如，简单的 GeoJSON Points 可以映射到 Place GeoSparql “知名文本” 表示，如下面的非规范性示例所示：
图例 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 知名文本替代方案：
示例 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:term，方法是为 ex: 前缀分配值 http://example.org/。
在 JSON-LD 中，紧凑 URI 前缀在 JSON-LD @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" 的属性。具体而言，紧凑 URI 可以用于任何期望 IRI (或 URI) 值的地方。
希望全面支持扩展的 Activity Streams 2.0 实现必须 支持由 JSON-LD 规范定义的紧凑 URI 展开。此类展开适用于所有属性名称，以及 JSON-LD @context 中显式定义为类型 @id 的所有属性值。
过度依赖紧凑 URI 形式可能会导致不同实现之间的歧义与互操作性问题。因此，除属性名称与 type 属性的值外，在所有其它情况下都应该 避免使用紧凑 URI。
5.2 扩展的重序列化
使用 JSON-LD 机制解析并重序列化包含扩展属性的 Activity Streams 2.0 文档的实现，应该 采取充分措施确保原始文档中使用的扩展属性得到保留并被适当序列化。
例如，考虑以下包含假设的 foo 与 bar 扩展属性的简单 Activity Stream 对象。foo 扩展定义在 JSON-LD @context 中，而 bar 扩展属性则没有。
图例 32 一个简单的扩展对象
示例 30
{
"@context" : [
"https://www.w3.org/ns/activitystreams" ,
{"foo" : "http://example.org/foo" }
],
"type" : "Note" ,
"content" : "这是一条简单的贴文" ,
"foo" : 123 ,
"bar" : 321
}
接收此贴文对象的实现可以选择将其作为普通 JSON 对象进行解析，也可以使用标准的 JSON-LD 展开算法。
若实现选择将其作为普通 JSON 解析，然后重序列化该对象（例如为了存储或再分发），那么它只需原样保留 @context, foo 与 bar 属性，并将它们包含在重序列化的输出中。
然而，若实现选择使用 JSON-LD 展开算法，@context 将从展开结果中移除，且 bar 属性将被映射到“空白节点” _:bar。若该文档随后使用规范性 Activity Streams 2.0 上下文重序列化，其 JSON-LD 压缩形式将为：
图例 33 重序列化后的压缩形式：
示例 31
{
"@context" : "https://www.w3.org/ns/activitystreams" ,
"type" : "Note" ,
"content" : "这是一条简单的贴文" ,
"http://example.org/foo" : 123 ,
"bar" : 321
}
虽然这很接近原始版本，但为 foo 属性使用完整展开的 URI 标签并不理想。为了确保重序列化的对象能被正确序列化，对接收到的文档执行 JSON-LD 展开的实现应该 保留执行 JSON-LD 展开时使用的原始 @context，然后在将对象重序列化为 JSON-LD 压缩形式时重用原始 @context。
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, 与 Zach Shepherd。
