この仕様は IRI [RFC3987] を 使っている。全ての URI [RFC3986] は IRI でもあるので、IRI という名前が付いているところでは URL を使うことが出来る。特別に考慮することが二つある: (1) URI ではない IRI が逆参照として与えられた場合、 [RFC3987] の 3.1 節のステップを使って URI にマッピングしなければならず(MUST)、 (2) IRI が "id" 値として提供された場合、そのようにマッピングしてはならない(MUST NOT)。
実装がコア語彙型と重複する拡張型を使用する場合、実装はコア語彙型も指定しなければならない(MUST)。例えば、いくつかの語彙(例えば、The Good Relations Vocabulary)は、位置を記述するための独自の型を定義する。例えば、http://purl.org/goodrelations/v1#Locationをオブジェクト型として使用したい実装は、以下に示すように、そのオブジェクトをPlaceとしても識別しなければならない。
{
"@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."
}
Figure 10 自動生成された概要を持つメモ
例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."
}
実装がコア語彙型と重複する拡張型を使用する場合、実装はコア語彙型も指定しなければならない(MUST)。For instance, some vocabularies (e.g.Schema.org) define their own types for describing actions. An implementation that wishes, for example, to use http://schema.org/LikeAction as an Activity MUST also identify that Object as being a Like as illustrated in the following:
Implementations are free to use Activity objects in both passive and imperative operations. In the passive sense, the Activity is used to record that an activity has or is occurring. In the imperative sense, the Activity can be used as a form of command, instructing an application to modify state in some manner consistent with the action being described. However, because this specification does not define a normative processing model that constrains how applications make use of the format, the distinction about whether an Activity statement is to be interpreted as a passive notification or as an imperative command can vary across implementations.
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Object",
"name": "This is the title"
}
Figure 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"
}
}
When specifying bidirectional text for a natural language value, and the base direction of the text cannot be correctly identified by the first strong directional character of that text, publishers SHOULD explicitly identify the default direction either by prefixing the value with an appropriate Unicode bidirectional control character, or by using HTML directional markup where permitted.
Consumers of Activity Streams 2.0 documents that contain bidirectional text SHOULD identify the base direction of any given natural language value by either scanning the text for the first strong directional character not contained within a markup tag; or by utilizing directional markup where provided. Once the base direction has been identified, consumers MUST determine the appropriate rendering and display of natural language values, according to the Unicode Bidirectional Algorithm [BIDI]. This may necessitate wrapping additional control characters or markup around the string prior to display, in order to apply the base direction.
属性
値
方向
手法
name
"פעילות הבינאום, W3C"
Right-to-Left
First strong directional character
name
"The document was titled, '\u2067פעילות הבינאום, W3C\u2069'"
Left-to-Right
First strong directional character
name
"\u200FHTML היא שפת סימון"
Right-to-Left
Bidi Control Character
name
"\u200E'سلام' is hello in Persian."
Left-to-Right
Bidi Control Character
summary
<p dir=\"rtl\">HTML היא שפת סימון>/p>
Right-to-Left
HTML Markup
summary
<p>פעילות הבינאום, W3C</p>
Right-to-Left
First strong directional character (ignoring markup)
summary
<p title="سلام">Hello</p>
Left-to-Right
First strong directional character (ignoring markup)
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{"foo": "http://example.org/foo"}
],
"type": "Note",
"content": "This is a simple note",
"foo": 123,
"bar": 321
}
An implementation that receives this Note object can choose to parse the object as an ordinary JSON object or it can use the standard JSON-LD Expansion algorithm.
If the implementation chooses to parse the object as ordinary JSON and then reserializes the object (e.g. for storage or redistribution), then it would simply preserve the values of the @context, foo and bar properties as they are and include those in the reserialized output.
However, if the implementation chooses to use the JSON-LD expansion algorithm, the @context will be removed from the expanded result and the bar property will be mapped to the "blank node" _:bar. If this document is then reserialized using the normative Activity Streams 2.0 context, the JSON-LD compacted form would be:
Figure 33再直列化されたコンパクト化形式:
Example 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ラベルを使用するのは同一ではない。To ensure that the reserialized object is serialized correctly, implementations that perform JSON-LD expansion of received documents SHOULD preserve the original @context used when performing the JSON-LD expansion, then reuse that when reserializing the object into the JSON-LD compacted form.
6. プライバシー上の考慮事項
Activity Streams 2.0 documents can (and likely will) contain potentially sensitive personal information such as identity, contact information, physical location, physical characteristics, and so forth. Furthermore, Activity data, in general, can be analyzed to generate profiles of the behavior of individual or groups of Actors.
Implementations that produce or consume Activity Streams 2.0 documents MUST take steps to openly and publicly document and communicate to all potential users: (a) the kinds of potentially sensitive personal information published, consumed or collected by the implementation, (b) the reasons for publishing, consuming and collecting that information, (c) the manner in which that information is being used, (d) the identity of any other party with whom that information is being shared, and (e) the reason the information is being shared with other parties.
Implementations that publish Activity Streams 2.0 documents SHOULD assume a default position of limiting both the kind and amount of sensitive personal information included in the document unless users have "opted in" to sharing additional detail.
Implementations that consume Activity Streams 2.0 documents SHOULD NOT, by default, store or share sensitive personal information included within consumed documents unless users have "opted in" to allowing that information to be stored or shared.
In this context, "opting in" does not necessarily require explicit action on the part of the user. If, for instance, the use of certain sensitive personal information is clearly implicit in the use of an implementation (a location tracking service, for example), then any use of that implementation can be considered an implicit acknowledgement that the sensitive personal information will be used and shared so long as the documentation guidelines listed above are followed.
7. セキュリティ上の考慮事項
Publishers or Consumers implementing Activity Streams as a stream of public data may also want to consider the potential for unsolicited commercial or malicious content and should take preventative measures to recognize such content and either identify it or not include it in their implementations.
Publishers should take reasonable measures to ensure potentially malicious user input such as cross-site scripting attacks are not included in the Activity Streams data they publish.
Consumers that re-emit ingested content to end-users MUST take reasonable measures if emitting ingested content to make sure potentially malicious ingested input is not re-emitted.
Consumers that re-emit ingested content for crawling by search engines should take reasonable measures to limit any use of their site as a Search Engine Optimization loophole. This may include converting untrusted hyperlinks to text or including a rel="nofollow" attribute.
Consumers should be aware of the potential for spoofing attacks where the attacker publishes activities or objects with falsified property values with the intent of injecting malicious content, hiding or corrupting legitimate content, or misleading users.
適合文書とは、文書のすべての適合基準に適合する文書である。For readability, some of these conformance requirements are phrased as conformance requirements on publishers; such requirements are implicitly requirements on documents: by definition, all documents are assumed to have a publisher.
Conforming documents must not include deprecated or obsolete syntax from Activity Streams 1.0. Conforming documents must include properties and types from the Activity Vocabulary. Conforming documents that use other vocabularies must also include equivalent Activity Vocabulary properties and types as illustrated in Section C. Conforming documents must not use features of JSON-LD or other serialization features disallowed in this specification, as in Section 2. Conforming documents that include types or properties beyond those defined in the Activity Streams 2.0 Vocabulary must use the extensibility features defined in section 5.
文書の例の非網羅的なリストには、以下が含まれる:
アクターを表現する文書
オブジェクトを表現する文書
アクティビティを表現する文書
アクターによって行われたアクティビティのコレクションを表現する文書
オブジェクトに行われたアクティビティのコレクションを表現する文書
アクターまたはオブジェクトにアドレス指定されたアクティビティのコレクションを表す文書
9.2 実装
Conforming implementations are software that publish, store, analyze, consume or otherwise process conforming documents. The two main kinds of implementations are publishers and consumers.
9.2.1 発行者
Conforming publishers are implementations that create and publish conforming documents. Conforming publishers must make conforming documents available according to the serialization requirements of section 2. Conforming publishers must consider privacy as described in section 6. Conforming publishers must consider security as described in section 7.
発行者の例の非網羅的なリストには、以下が含まれる:
ソーシャルネットワーク
個人的なwebサイト
文書発行システム
非適合ソーシャルネットワークからのブリッジ
RSSやAtomのような似たような文書型からの文書コンバータ
9.2.2 消費者
Conforming consumers are implementations that read and analyze conforming documents. Conforming consumers must tolerate deprecated or obsolete properties or types from Activity Streams 1.0. Conforming consumers must ignore properties or types that are not applicable to their application domain.
Conforming consumers may re-publish conforming documents in other other data formats. Conforming consumers may present conforming documents to a user on screen, in print, in audio format, or using other presentation mechanisms. Conforming consumers must faithfully translate the information represented in conforming documents into these other formats or media. Conforming consumers that re-publish conforming documents must consider privacy as described in section 6 and security as described in section 7.
消費者の例の非網羅的なリストには、以下が含まれる:
ソーシャルネットワーク
検索エンジン
フィードリーダ
文書バリデータ
フィードアグリゲータ
静的アナライザ
A. 謝辞
Activity Streams 2.0仕様は、W3CSocial Web Working Groupの成果物である。編集者は、現在の仕様を形成するのに役立った会話、問題、テストに貢献したすべてのワーキンググループメンバーに感謝する。
編集者はまた、W3CSocial Web Working Groupへの貢献として仕様が取り上げられる前に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。
B. 廃止されたActivity Streams 1.0文法
この節は非規範的である。
注意: この付録は非規範的であるが、MUSTのような規範的用語を使う。Where used, the meaning is to indicate what would be required to properly implement the Activity Streams 1.0 backwards compatibility model described in this appendix if an implementer chose to do so.
While the syntax defined by this specification diverges from that defined by JSON Activity Streams 1.0, the fundamental model defined by that original specification remains intact. Specific processing rules are defined by this specification that allow existing Activity Streams 1.0 documents to be mapped to and processed as an Activity Streams 2.0 document.
The JSON syntax defined by this specification differs somewhat from that defined in the original JSON Activity Streams 1.0 [ AS1] specification in ways that are not backwards compatible. Implementations can choose to continue supporting the JSON Activity Streams 1.0 syntax but ought consider it to be deprecated. This means that while implementations can continue to consume the 1.0 syntax, they should not output the 1.0 syntax unless specifically interacting with older non-2.0 compliant implementations.
Specifically:
Implementations can use the "application/stream+json" MIME media type when producing a JSON serialization using the Activity Streams 1.0 syntax, and "application/activity+json" when producing a serialization conforming to the 2.0 syntax.
Implementations that process serializations identified using either the "application/stream+json" or the more generic "application/json" MIME media type MUST follow the syntax and processing rules set by [AS1]. The 2.0 syntax and processing rules apply only when handling serializations using the "application/activity+json" media type.
When processing Activity Streams 1.0 documents using a JSON-LD processing model, implementations can use the special AS 1.0 to AS 2.0 expansion @context definition provided here to produce the JSON-LD expanded representation. Refer to the JSON-LD Processing Algorithms and API for details.
When processing Activity Streams 1.0 documents and converting those to 2.0, implementations ought to treat id as an alias for the JSON-LD @id key word; and the objectType and verb properties as aliases for the JSON-LD @type keyword.
Activity Streams 1.0 uses the displayName property which has been renamed to name in Activity Streams 2.0. Implementations ought to treat displayName as an alias for name.
Activity Streams 1.0 uses the title property which has been dropped from Activity Streams 2.0. Implementations processing Activity Streams 1.0 documents as Activity Streams 2.0 ought to treat instances of the title property as an extension.
This document redefines the content and summary properties as natural language values which means their values can be expressed as either a string or an object mapping language tags to string values. In the 1.0 syntax, these are expressed solely as String values. Because the 1.0 values are a valid subset allowed by this specification, implementations are not required to take any specific action to continue supporting those values.
This document redefines a large number of common properties defined originally as Objects in 1.0 as either Objects or Links. The JSON-LD serialization allows such property values to be expressed as either an IRI String, an JSON object, or an Array of IRI Strings and JSON objects. Because the 1.0 values are a valid subset allowed by this specification, existing implementations are not required to take any specific action to continue supporting those values.
This specification deprecates the upstreamDuplicates and downstreamDuplicates properties defined by Activity Streams 1.0 and does not provide a replacement. This is due largely to lack of any reasonable implementation evidence. While the upstreamDuplicates and downstreamDuplicates properties MAY continue to be used, implementations SHOULD avoid them.
In Activity Streams 1.0, the "post" verb was defined to describe the action of both creating an object and "posting" or uploading it to a service. This specification replaces the "post" verb with separate Create and Add Activity types. When processing Activity Streams 1.0 documents and converting those into 2.0, implementations SHOULD treat instances of the " post" verb as equivalent to Createif there is no target property specified; and equivalent to Addif there is a target property specified.
By following these guidelines, all JSON Activity Streams 1.0 serializations can be processed successfully by 2.0 implementations.
C. 複数の語彙を使った例
この節は非規範的である。
It is possible use multiple vocabularies to cover particular characteristics of the activities like data provenance and annotations, which can compliment the Activity Vocabulary. For example: Eric writes a short note to be shared with his followers. After posting the note, he notices a spelling error. He edits the note and re-posts it. Later, Eric decides that the information in the note is incorrect. He deletes the note.
Figure 34A series of activities; creating, editing, and deleting a note.
