2.1 JSON-LD

序列化后的 JSON 形式的 Activity Streams 2.0 文档，必须与标准 JSON-LD 1.0 处理算法和 API [JSON-LD-API] 压缩算法生成的结果一致，并且至少要使用本规范性 JSON-LD @context 定义。实现可以通过附加其它 @context 定义进行扩展，但不得覆盖或更改规范性 context。实现可以使用未在 JSON-LD @context 定义中的其他属性和值，但需明白，采用标准 JSON-LD 算法的实现可能不会支持或忽略这些扩展属性。详见可扩展性部分。

JSON-LD 使用特殊的 @context 属性定义处理上下文。@context 属性的取值由 [JSON-LD] 规范规定。 生成 Activity Streams 2.0 文档的实现应包含一个以 "https://www.w3.org/ns/activitystreams" 作为值的 @context 属性，引用规范性 Activity Streams 2.0 JSON-LD @context 定义。实现可以使用备用 URL "http://www.w3.org/ns/activitystreams"。取值既可为字符串，也可为对象或数组。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "A note",
  "type": "Note",
  "content": "My dog has fleas."
}

{
  "@context": {
     "@vocab": "https://www.w3.org/ns/activitystreams",
     "ext": "https://canine-extension.example/terms/",
     "@language": "en"
  },
  "summary": "A note",
  "type": "Note",
  "content": "My dog has fleas.",
  "ext:nose": 0,
  "ext:smell": "terrible"
}

{
  "@context": [
     "https://www.w3.org/ns/activitystreams",
     {
      "css": "http://www.w3.org/ns/oa#styledBy"
     }
  ],
  "summary": "A note",
  "type": "Note",
  "content": "My dog has fleas.",
  "css": "http://www.csszengarden.com/217/217.css?v=8may2013"
}

当支持 JSON-LD 的 Activity Streams 2.0 实现遇到 MIME 类型为 "application/activity+json" 的 JSON 文档且其中不包含引用规范性 Activity Streams 2.0 JSON-LD @context 定义 的 @context 属性时，实现仍必须假定该规范性 @context 依然生效。

2.2 IRIs 与 URLs

本规范采用 IRIs [RFC3987]。每个 URI [RFC3986] 也是一个 IRI，可在要求 IRI 的场景下直接用 URI。有两个注意点：(1) 当出现 IRI 但不是 URI 且需被解析时，必须按 [RFC3987] 3.1 节所述映射为 URI；(2) 当 IRI 用作"id"值时，不得进行此映射。

建议不在 Activity Streams 2.0 文档中使用相对 IRI（或 URL）引用，因为许多 JSON 解析器无法可靠保留用于解析相对引用的基础上下文。

2.3 日期和时间

所有带日期和时间属性的值必须符合 [RFC3339] 的 “date-time” 语法，只是秒可以省略。大写 "T" 用于分隔日期与时间，大写 "Z" 用于无数字时区偏移的情况，必须使用。

规范如下 [ABNF] 语法描述。 构造 "time-hour", "time-minute", "time-second", "time-secfrac", "time-offset" 和 "full-date" 参见 [ RFC3339]。

as2-partial-time = time-hour ":" time-minute [":" time-second]
                   [time-secfrac]
as2-full-time    = as2-partial-time time-offset
as2-date-time    = full-date "T" as2-full-time

需要注意的是，`time-offset` 组件不等同于时区。虽然带 time-offset 的时间适用于时间戳，但没有额外信息和处理，无法可靠地与本地“墙上时间”互相转换。

4.1 Object

Object 是 Activity Streams 词汇表的主基类。

除了拥有全局标识（用 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）。

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

Activity Vocabulary 定义了一系列适用于许多社交Web应用的 Object 类型。本规范不为这些对象中的大多数定义具备语义特性的专用属性。如需补充更多细节可借助外部词汇表表达。

此外，虽然实现可以自由引入超出 Activity Vocabulary 定义的新 Object 类型，但如果应用过度依赖其他实现无法识别的扩展类型，则可能产生互操作性问题。应注意不要与已有对象类型重复或重叠。

当实现使用的扩展类型与核心词汇类型重叠时，实现 必须 同时注明核心词汇类型。例如，有些词汇表（如 Good Relations Vocabulary）为地点定义了自己的类型。实现者如果希望使用 http://purl.org/goodrelations/v1#Location 作为对象类型，则 必须 同时标明该对象为 Place，如下面所示：

{
  "@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 中定义的属性。

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

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

4.2 Link

Link 描述了到另一个资源的带限定、间接引用，其概念模型与 [RFC5988] 中定义的 Links 非常贴近。Link 对象的属性并非被引用资源本身的属性，而是为渲染代理提供使用该资源的提示。例如，height 和 width 可表示期望渲染的图片尺寸，而非实际像素数。

Link 的目标 URI 通过必需的 href 属性定义。此外，所有 Link 实例还拥有如下由 Activity Vocabulary 规范性定义的一组可选属性： id | name | hreflang | mediaType | rel | height | width

例如，所有 Object 都可以包含 image 属性，其值描述了包含对象的图形表示。通常该属性用于为用户提供可显示图片资源（如 JPEG、GIF、PNG）的URL。一个对象可以有多个此类视觉表示——比如多张截图，或不同分辨率的同一图片。在 Activity Streams 2.0 中，描述此类引用主要有三种写法。

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

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

形式上，前一个示例建立了与图片资源的无条件直接关联，后面这种则是带限定条件的间接关联，可指定更多关于该关联的属性。

{
  "@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 对象的 rel 属性即为链接关系值。如果未指定 rel，则表示链接关系未定义。单个 Link 可拥有多个链接关系值。JSON 序列化时，单一链接关系用字符串，多个用字符串数组表示。

链接关系的作用域为 Link 所在的直接父对象。

下例展示了两个引用。第一个未指定链接关系，第二个则指定了链接关系为 "thumbnail"。

{
  "@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] 稍有不同。HTML5 规定，任何不包含 "空格" U+0020、"tab"（U+0009）、"LF"（U+000A）、"FF"（U+000C）、"CR"（U+000D）或 ","（U+002C）字符的字符串都可作为有效的 link relation。为促进互操作性，Activity Streams 2.0 的实现 必须 仅使用同时满足 [RFC5988] 和 [HTML5] 语法的链接关系值。实现 可以 使用未注册的 link relation 值。

请注意，Link 和 Object 类型互不交叉。也就是说，任意 Object 不能同时为 Link。

4.3 参与者（Actor）

参与者对象是基础 Object 类型的特化，代表能够执行活动的实体。活动词汇表规范性地定义了五类具体的参与者类型： Application（应用） | Group（群组） | Organization（组织） | Person（个人） | Service（服务）。

本规范对参与者仅作最通用定义，并未对每一类参与者规定语义上的专用属性。所有 Actor 对象均为 Object 的特化，并继承所有 Object 的核心属性。如有未被活动词汇表覆盖的更多细节，可利用外部词汇表表达。对于 Person、Group 和 Organization 实例，建议使用 VCard [ vcard-rdf] 补充元数据。

{
  "@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 活动（Activity）

活动对象是基础 Object 类型的特化，用于表达已经发生、正在发生或可能发生的动作。

除了继承所有 Object 实例支持的通用属性外，Activity 对象还支持如下由词汇表定义的附加属性： actor | object | target | origin | result | instrument

type 属性用于标识该活动语句所表达的动作类型。

{
  "@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 类型。本规范不为其中多数活动定义语义专用属性。可以用外部词汇表补充活动词汇表未覆盖的更多细节。

实现可自由引入核心词汇以外的新类型 Activity，但如应用过于依赖其它实现无法识别的扩展类型，可能造成互操作性问题。应避免与已有 Activity 类型重复或重叠。

当实现中使用的扩展类型与核心词汇类型重叠时，必须同时指定核心类型。例如，部分词汇表（如 Schema.org）自定义动作类型。如实现希望使用 http://schema.org/LikeAction 作为 Activity 类型，必须 也声明为 Like，如下例所示：

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

Activity 对象既可用于被动场景（用于记录已发生或正在发生的活动），也可用于指令场景（用作指令，通知应用根据描述的动作修改状态）。由于本规范未定义活动对象处理的规范性模型，具体应被解读为被动通知还是命令行为，留给实现决定。

4.5 非及物活动（IntransitiveActivity）

非及物活动对象是 Activity 类型的特化，用于表达非及物动作。IntransitiveActivity 对象不包含 object 属性。

4.6 集合（Collection）

Collection 对象是基础Object的特化，用作其他 Object 或 Link 的容器。

除了继承所有 Object 的基础属性外，所有Collection 类型还包含以下扩展属性： items | totalItems | first | last | current

Collection 内的项目可以是有序的，也可以是无序的。OrderedCollection 类型 可以 用于声明集合始终有序。在 JSON 序列化中，集合的无序项用 items 属性表示，有序项用 orderedItems 属性表示。

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

{
  "@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 集合分页（Collection Paging）

一个 Collection 可能包含大量子项，通常实现者很难将其所有内容仅用 items（或 orderedItems）全部序列化。这种情况下，Collection 内项目可划分为不同的子集或“分页”。分页以 CollectionPage 类型表示。

CollectionPage 类型继承自 Collection，拥有全部父类型属性。此外还可以指定以下附加属性： partOf | next | prev |

partOf 属性用于标识 CollectionPage 中子项隶属于的 Collection。

first、next、prev、last 和 current 属性用于引用父集合其它包含子集的 CollectionPage 实例。

与 Collection 对象一样，CollectionPage 的条目可有序也可无序。OrderedCollectionPage 类型 可以用于声明分页中的条目严格按顺序排列。

OrderedCollectionPage 类型同时扩展自 CollectionPage 和 OrderedCollection 。除了继承各自属性，OrderedCollectionPage 还可包含附加 startIndex 属性，表示本页首项在所属 OrderedCollection 中的相对序号。

无论有序还是无序，一个 Collection 的分页通常按顺序组织（单向或双向链表）。first 用于指向序列中的第一页，last 用于指向序列末页，prev 和 next 分别指向前一页和后一页。

current 属性用于指向 Collection 当前最新创建或更新子项所在的分页。

first、last、next、prev 及 current 属性的值既可为单个 CollectionPage ，也可为一个 Link，指向包含 CollectionPage 的独立资源。

示例 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) 一个 JSON 对象，将规范 [BCP47] 语言标签映射到同一字符串的各地化等价翻译。在序列化 JSON 里，通过简单的属性命名规则区分这两种形式，例如："name" 代表 name 属性的字符串形式，而 "nameMap" 代表对象形式。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Object",
  "name": "This is the title"
}

{
  "@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] 语言标签。对应的值必须是字符串。

活动词汇表定义了三种使用自然语言值的属性： name、 summary 和 content。因此，在 JSON 序列化中，" name"、"summary" 和 "content" 表示字符串形式；" nameMap"、"summaryMap" 和 " contentMap" 表示对象形式。

对于语言未知或未确定的值，对象形式中可以显式用特殊语言标签 "und" 进行标识。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Object",
  "nameMap": {
    "und": "This is the title"
  }
}

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "@language": "en"
    }],
  "type": "Object",
  "name": "This is the title"
}

4.8 语言标记

若已知，Activity Streams 2.0 发布者应当显式标记自然语言属性的语言，可使用 map 属性或默认语言标签。

5.1 紧凑 URI 支持

JSON-LD 语法支持“紧凑 URI”的用法。紧凑 URI 利用已定义前缀对 URI 进行简化编码。例如，URI http://example.org/term 可通过分配 ex: 前缀为 http://example.org/，写作 ex:term。

在 JSON-LD 中，紧凑 URI 前缀在 @context 定义内声明。例如：

{
"@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 没有。

{
  "@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 属性及其值。

如果采用 JSON-LD 扩展算法，@context 会在扩展结果中被移除，bar 属性会被映射为“空白节点” _:bar。如用 Activity Streams 2.0 规范上下文再序列化，JSON-LD 压缩之后形式如下：

{
  "@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 再压缩时复用之。

8.1 application/activity+json 媒体类型

本规范注册了 application/activity+json 媒体类型专门用于标识符合 Activity Streams 2.0 格式的文档。

profile-param = "profile=" profile-value
profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
profile-URI   = URI

请注意，虽然 Activity Streams 2.0 格式采用 JSON-LD 规范，但为 Activity Streams 2.0 实现增加了多个限制和要求，故需要独立媒体类型。

由于 Activity Streams 2.0 可视为 JSON-LD 的受限特型，实现建议把 `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` 媒体类型视为等效于 `application/activity+json`。

9.1 文档

一致性文档是指完全符合所有文档级一致性标准的文档。为了便于阅读，部分一致性要求表述为发布方应当遵守，但实际上这些要求皆视为对文档的要求，因为所有文档都假定有发布者。

一致性文档不得包含 Activity Streams 1.0 的弃用或过时语法，必须包含活动词汇表中的属性与类型。使用其他词汇表的一致性文档还必须包含等价的活动词汇表属性与类型（详见 C 节）。一致性文档不得使用本规范禁止的 JSON-LD 或其它序列化特性（详见第2节）。超出 Activity Streams 2.0 词汇定义的类型或属性，须用第5节定义的扩展机制。

一致性文档举例（包括但不限于）：

• 表达参与者的文档
• 表达对象的文档
• 表达活动的文档
• 表达某一参与者参与的活动集合文档
• 表达某一对象相关活动集合文档
• 表达发送给某参与者或对象的活动集合文档

9.2 实现

一致性实现是指任何发布、存储、分析、消费或以其他方式处理一致性文档的软件。主要有发布方和消费方两类。