Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
This specification details a model for representing potential and completed activities using the JSON format.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Social Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-socialweb@w3.org (subscribe, archives). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 September 2015 W3C Process Document.
In the most basic sense, an "Activity" is a semantic description of an action. It is the goal of this specification to provide a JSON-based syntax that is sufficient to express metadata about activities in a rich, human-friendly but machine-processable and extensible manner. This can include constructing natural-language descriptions or visual representations about the activity, associating actionable information with various types of objects, communicating or recording activity logs, or delegation of potential actions to other applications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This section is non-normative.
The JSON Activity Streams 1.0 [AS1] specification was published in May of 2011 and provided a baseline extensible syntax for the expression of completed activities. This specification builds upon that initial foundation by incorporating lessons learned through extensive implementation, community feedback and related ongoing work from a variety of other communities.
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.
This specification incorporates several existing extensions to the 1.0 syntax directly into the 2.0 model. These include portions of the Activity Streams 1.0 Base Schema, Audience Targeting, Responses, and Priority extensions.
This specification describes a JSON-based [RFC7159] serialization syntax for the Activity Vocabulary that follows the conventions defined by the [JSON-LD] specification. While serialization forms other than JSON-LD are possible, alternatives are not discussed by this document.
When serialized, absent properties are represented by either (a) setting the property value to null, or (b) by omitting the property declaration altogether at the option of the publisher; these representations are semantically equivalent. If a property has an array value, the absence of any items in that array MUST be represented by omitting the property entirely or by setting the value to null. The appropriate interpretation of an omitted or explicitly null value is that no value has been assigned as opposed to the view that the given value is empty or nil.
This specification uses IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. There are two special considerations: (1) when an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as an "id" value, it MUST NOT be so mapped.
Unless otherwise specified, all properties with date and time values MUST conform to the "date-time" production in [RFC3339], with an uppercase "T" character used to separate date and time, and an uppercase "Z" character in the absence of a numeric time zone offset. All such timestamps SHOULD be represented relative to Coordinated Universal Time (UTC).
An Activity Streams
Document is a JSON-LD document whose root value is an
Activity Streams Object of any type and whose MIME media
type is "application/activity+json
".
Activity Streams 2.0 documents MUST be serialized using the UTF-8 character encoding.
The serialized JSON form of an Activity Streams 2.0 document MUST be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here. Implementations MAY augment the provided @context with additional @context definitions but MUST NOT override or change the normative context. Implementations MAY also include in the serialized JSON document additional properties and values not defined in the JSON-LD @context with the understanding that any such properties will likely be unsupported and ignored by consuming implementations that use the standard JSON-LD algorithms. See the Extensibility section for more information on handling extensions within Activity Streams 2.0 documents.
This section is non-normative.
Following are three examples of activities with varying degrees of detail. Each of the examples uses an implied JSON-LD @context equal to that provided here.
Note that the Activity Streams JSON-LD @context maps the prefix
"as:
" to the base URI
"http://www.w3.org/ns/activitystreams#
". This means that
terms such as "as:Activity
" are equivalent to the expanded
form "http://www.w3.org/ns/activitystreams#Activity
". In
order to best illustrate that implementors MUST support both forms, both
the compact and expanded forms are used interchangeably by the examples
in this document.
Each example is shown using the normative JSON-LD serialization defined by this specification along with generally equivalent, non-normative Microdata, RDFa, Microformats, and Turtle serializations. These non-JSON-LD alternatives are included solely for illustrative purposes.
This section is non-normative.
The Microdata, RDFa and Microformats examples included in this document are purely informative and may not currently reflect actual implementation experience or accepted best practices for each format. These alternate serializations may be removed from future iterations of this document and moved to a separate informative WG Note.
The examples included in this document all use HTTP URLs for @id values. These values are not limited to URLs and it is perfectly legal to use HTTPS URLs or any URI, URN, or IRI value for the @id.
The Activity Vocabulary
defines the abstract model for Activity Streams 2.0. The vocabulary
is segmented into a set of nine core classes and an extended set of
Activity and Object types common to most social Web applications. The
core classes include:
Object,
Link,
Actor,
Activity,
IntransitiveActivity,
Collection,
OrderedCollection
,
CollectionPage
,
and OrderedCollectionPage
.
Each of these classes is described and illustrated below. The extended
Activity and Object types are defined normatively in the Activity
Vocabulary specification.
The Object
class is the primary base class for the Activity Streams vocabulary.
In addition to having a global identifier (expressed as an absolute IRI
using the JSON-LD @id
keyword) and an "object type"
(expressed using the JSON-LD @type
keyword), all instances
of the Object
class share a common set of properties
normatively defined by the
Activity Vocabulary.
These include:
alias
|
attachment
|
attributedTo
|
content
|
context
|
contentMap
|
displayName
|
displayNameMap
|
endTime
|
generator
|
icon
|
image
|
inReplyTo
|
location
|
preview
|
published
|
replies
|
scope
|
startTime
|
summary
|
summaryMap
|
tag
|
title
|
titleMap
|
updated
|
url
|
to
|
bto
|
cc
|
bcc
Previous versions of the Activity Streams format used the
objectType
property to identify the object type. The
objectType
property MUST NOT be used within an Activity
Streams 2.0 document to represent object type.
While all properties are optional, all Object
instances
SHOULD at least contain either the
displayName
or displayNameMap
.
Implementations MUST treat all object types in an Activity Streams document as subclasses of Object unless the object is a Link.
The Activity Vocabulary
defines a broad range of Object
types that are common to
many social Web applications. This specification stops short of
defining semantically specific properties for most of these objects.
External vocabularies can be used to express additional detail not
covered by the Activity Vocabulary.
Furthermore, while implementations are free to introduce new types of
Objects beyond those defined by the Activity Vocabulary, interoperability
issues can arise when applications rely too much on extension types that
are not recognized by other implementations. Care should be taken to not
unduly overlap with or duplicate the existing Object types. For instance,
some vocabularies (e.g. The Good Relations Vocabulary) define their own
classes for describing locations. An implementation that wishes, for
example, to use a
http://purl.org/goodrelations/v1#Location
as an object type SHOULD also identify the object as being both a
Place
and an
http://purl.org/goodrelations/v1#Location
, as
illustrated in the following:
Certain properties defined by some External Vocabularies can overlap or duplicate those defined by the Activity Vocabulary. Where such overlap exists, for the sake of consistent interoperability, implementers MUST favor the use of properties defined by the Activity Vocabulary.
Several properties defined by the
Vocabulary are defined
as having natural language values. These are representations of
human-readable character sequences using one or more languages.
Within the JSON-LD serialization, they are expressed as either (1) a
single JSON string or (2) a JSON object mapping [RFC5646]
Language-Tags to localized, equivalent translations of the same string
value. In [JSON-LD], such constructs are referred to as "Language
Maps". In the serialized JSON-LD, these two forms are differentiated
using a simple property naming convention, for instance:
"displayName
" identifies the JSON string form for the
displayName
property while "displayNameMap
" represents the Language
Map form.
Every key in the Language Map form MUST be a valid [RFC5646] Language-Tag. The associated values MUST be Strings.
The Activity Vocabulary
defines four specific natural language values:
displayName
,
title
,
summary
, and
content
.
Accordingly, the Activity Streams
JSON-LD
@context definition respectively maps the terms
"displayName
",
"title
", "summary
", and
"content
" for representing the JSON string forms and the
terms "displayNameMap
", "titleMap
",
"summaryMap
", and "contentMap
" for
representing the Language Map forms.
The default language for document or an individual object can be
established using the JSON-LD @language
keyword within a
@context
definition. For instance:
The JSON-LD format generally supports one additional way of associating language tag information with a literal string value using what JSON-LD calls a "value object", as illustrated below:
Activity Streams 2.0 implementations SHOULD NOT use JSON-LD value objects in this manner. Implementations SHOULD, instead, use the Language Map form. The one situation where use of the value object cannot be avoided is when a default language context has been established and a particular language-sensitive field needs to be explicitly excluded from that context, as in the following example:
By explicitly omitting the @language
from the value
of displayName
in the JSON-LD example, the
displayName
is excluded from the default language context.
However, because this mechanism requires specific understanding of JSON-LD
algorithms, and makes the publisher's intention less obvious and visible,
implementations SHOULD avoid such cases as much as possible.
A Link
describes a qualified, indirect reference to another
resource that is closely related to the conceptual model of Links as
established in [RFC5988].
The target URI of the Link is expressed using the required
href
keyword. In addition, all Link
instances share the
following common set of optional properties as normatively defined by
the Activity Vocabulary:
displayName
|
displayNameMap
|
hreflang
|
mediaType
|
rel
|
title
|
titleMap
|
height
|
width
|
duration
For example, all Objects can contain an
image
property whose value describes a graphical representation of the
containing object. This property will typically be used to provide the
URL to an image (e.g. JPEG, GIF or PNG) resource that can be displayed
to the user. Any given object might have multiple such visual
representations -- multiple screenshots, for instance, or the same
image at different resolutions. In Activity Streams 2.0, there are
essentially three ways of describing such references.
Formally, the former example establishes an unqualified
direct relationship with the image resource while the
latter creates a qualified,
indirect relationship that allows additional properties about the
relationship to be specified. Such properties (e.g. mediaType
,
hreflang
, rel
, etc) describe the Link
itself as opposed to describing the referenced resource. For many
practical applications, this distinction will likely be fairly
insignificant but it is still worth keeping in mind.
Individual items contained in such an array are independent of the others and no significance is given to the ordering.
RFC 5988 defines that all Links have a "link relation" that describes
the contextual purpose of the link. Within a Link,
the rel
property
provides the link relation value. If no rel
property is
specified, the link relation is considered to be unspecified. Any given
Link can have multiple link relation values. In the JSON-LD
serialization, A single link relation is expressed as a single JSON
string. Multiple link relations are expressed as an array of JSON
strings.
In the following example, two separate references are provided. The
link relation of the first is unspecified, while the link relation of
the second is "thumbnail
".
It ought to be noted that the [HTML5] specification provides its own alternative definition of a "link relation" that differs slightly from the [RFC5988] definition. In the HTML5 definition, any string that does not contain the "space" U+0020, "tab" (U+0009), "LF" (U+000A), "FF" (U+000C), "CR" (U+000D) or "," (U+002C) characters can be used as a valid link relation. To promote interoperability, Activity Streams 2.0 implementations MUST only use link relations that are valid in terms of both the [RFC5988] and [HTML5] definitions.
Note that the Link and Object classes are disjoint from one another. That is, any given Object cannot also be a Link.
Actor objects are specializations of the base Object
type that represent entities capable of carrying out an
Activity. The Actor class is the base class for all
Actor objects. The Activity
Vocabulary provides the normative definition of six specific
types of Actors:
Application
|
Group
|
Organization
|
Person
|
Process
|
Service
.
This specification intentionally defines Actors in only the most
generalized way, stopping short of defining semantically specific
properties for each. All Actor objects are specializations of
Object
and inherit all of the core properties
common to all Objects. External vocabularies can be used to express
additional detail not covered by the Activity Vocabulary. VCard
[vcard-rdf] SHOULD be used to provide additional metadata for
Person,
Group,
and Organization instances.
While implementations are free to introduce new types of Actors beyond
those defined by the Activity Vocabulary, interoperability issues can
arise when applications rely too much on extension types that are not
recognized by other implementations. Care should be taken to not unduly
overlap with or duplicate the existing Actor types. For instance, some
vocabularies (e.g. VCard) define their own classes for describing
people. An implementation that wishes, for example, to use a
vcard:Individual
as an Actor SHOULD identify that Actor as
being both a Person
and an vcard:Individual
, as illustrated in the following:
Activity objects are specializations of the base Object type that provide information about actions that have either already occurred, are in the process of occurring, or may occur in the future.
In addition to common properties supported by all Object
instances, Activity
objects support the following additional
properties defined by the Vocabulary:
actor
|
object
|
target
|
origin
|
result
|
priority
|
instrument
The JSON-LD @type
keyword is used to identify the type
of action the Activity Statement represents. Previous versions of the
Activity Streams format used the verb
property to identify
the action type. The verb
MUST NOT be used within an
Activity Streams 2.0 Activity to represent the action type.
The Activity Vocabulary
defines a broad range of Activity
types that are common to
many social Web applications. This specification stops short of
defining semantically specific properties for most of these activities.
External vocabularies can be used to express additional detail not
covered by the Activity Vocabulary.
Furthermore, while implementations are free to introduce new types of
Activites beyond those defined by the Activity Vocabulary,
interoperability issues can arise when applications rely too much on
extension types that are not recognized by other implementations. Care
should be taken to not unduly overlap with or duplicate the existing
Activity types. For instance, some vocabularies (e.g. Schema.org) define
their own classes for describing actions. An implementation that wishes,
for example, to use http://schema.org/LikeAction
as an Activity SHOULD identify that Object as being both a
Like
and an http://schema.org/LikeAction
, 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 been whether an Activity statement is intended to be interpreted as a passive notification or as an imperative command can vary across implementations.
Collection
objects are a specialization of the
base Object
that act as a container for other
Objects or Links.
In addition to the base properties inherited by all
Objects
, all
Collection
types contain the additional properties:
items |
totalItems |
first |
last |
current
The items within a Collection
can be ordered or
unordered. The OrderedCollection
type can be
used to identify a Collection whose items are always ordered. In the
JSON-LD serialization, the unordered items of a Collection are
represented using the items
property while ordered items
are represented using the orderedItems
property.
The normative JSON-LD @context definition maps each of the
items
and orderedItems
properties to the
Activity Vocabulary items
term. The orderedItems
term, however, is defined in
the JSON-LD @context as @container = @list
, indicating
that it's members are strictly ordered.
A Collection can contain a large number of items. Often, it becomes
impractical for an implementation to serialize every item contained
by a Collection using the items
(or
orderedItems
) property alone. In such cases, the items
within a Collection can be divided into distinct subsets or "pages".
A page is represented using the CollectionPage
type.
The
type extends from the base
CollectionPage
Collection
type and inherits all of it's
properties. The following additional properties can also be
specified:
partOf |
first |
next |
prev |
last |
current |
The partOf
property identifies the
Collection
to which the items contained by the
CollectionPage
belong.
The first
, next
, prev
,
last
, and current
properties are used
to reference other
instances
that contain additional subsets of items from the parent collection.
CollectionPage
As with Collection
objects, the items within a
CollectionPage
might be ordered or unordered.
The OrderedCollectionPage
type can be used
to identify a page whose items are strictly ordered.
The
type extends from
both OrderedCollectionPage
and
CollectionPage
. In addition to the properties
inherited from each of those, the OrderedCollection
OrderedCollectionPage
may contain an additional
startIndex
property whose value indicates the relative index position
of the first item contained by the page within the
OrderedCollection
to which the page belongs.
Whether ordered or not, the pages of a Collection
are
typically arranged in a sequence (either a singly or doubly-linked
list). The first
property is used to identify the first
page in this sequence, while the last
property is used
to identify the final page in the sequence. The prev
and
next
properties identify the pages immediately before
and immediately following, respectively.
The current
property identifies a page
containing the subset of items in the Collection
that
have been created or updated most recently.
The values for the first
, last
,
next
, prev
, and current
properties can be either a single
or a CollectionPage
Link
referencing a separate resource
containing a
.
CollectionPage
Using paging with an OrderedCollection
can be tricky
because there are no guarantees that implementations will process the
sequence of pages in any predictable order. Implementations that wish
to reconstruct the appropriate complete ordering of member items in
the logical collection should navigate to the first (or last)
page in the sequence then recursively follow the next
(or prev
) link until all pages have been processed.
If the pages of an OrderedCollection
are not instances
of OrderedCollectionPage
, an implementation will have
no reliable means of reconstructing the appropriate ordering of items.
Conceptually, every Object has both a Primary and Secondary audience. The Primary audience consists of those entities directly involved or owning the object. The Secondary audience consists of the collection of entities sharing an interest in the object but who might not be directly involved (e.g."followers").
For instance, suppose a social network of three individuals: Bob, Joe and Jane. Bob and Joe are each friends with Jane but are not friends with one another. Bob has chosen to "follow" activities for which Jane is directly involved. Jane shares a file with Joe.
In this example, Jane and Joe are each directly involved in the file sharing activity and together make up the Primary Audience for that event. Bob, having an interest in activities involving Jane, is the Secondary Audience. Knowing this, a system that produces or consumes the activity can intelligently notify each person of the event.
While there are means (based on the action type, actor, object and
target of the activity) to infer the primary audience for many types of
activities, heuristics do not work in every case and do not provide a
means of identifying the secondary audience. The
to
,
cc
,
bto
and
bcc
properties MAY be used within an Object to explicitly identify the
Primary and Secondary audiences.
The prototypical use case for an Object containing these properties is the publication and redistribution of objects through an intermediary. That is, an event source generates the object and publishes it to the intermediary which determines a subset of items to display to specific individual users or groups. Such a determination can be made, in part, by identifying the Primary and Secondary Audiences for each object.
When the event source generates the object and specifies values for
the to
and cc
fields, the intermediary SHOULD
redistribute that object with the values of those fields intact, allowing
any processor to see who the object has been targeted to. This is
precisely the same model used by the to
and cc
fields in email systems.
There are situations, however, in which disclosing the identity of
specific members of the audience may be inappropriate. For instance,
a user may not wish to let other users know that they are interested
in various topics, individuals or types of events. To support this
option, an implementation generating an object MAY use the
bto
and bcc
properties to list
entities to whom the object should be privately targeted. When an
intermediary receives an object containing these properties, it
MUST remove those values prior to redistributing the object. The
intent is that systems MUST consider entities listed within the
bto
and bcc
properties as
part of the Primary and Secondary audience but MUST NOT disclose that
fact to any other party.
Audience targeting information included within an Object only
describes the intent of the object creator. With clear exception
given to the appropriate handling of bto
and
bcc
, this specification leaves it up to implementations
to determine how the audience targeting information is used.
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 SHOULD consider it to be deprecated. This means that while implementations MAY 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:
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.
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.
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.
displayName
,
title
,
content
and
summary
properties as natural language values which means their values can be expressed
as either a String or a JSON-LD Language Map. 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.
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.
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
Create
if there is no target
property specified; and
equivalent to
Add
if there is a target
property specified.
By following these requirements, all JSON Activity Streams 1.0 serializations can be processed successfully by 2.0 implementations.
In Activity Streams 2.0, an "extension" is any property not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined. Accordingly, implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
It is important to note that the JSON-LD Processing Algorithms [JSON-LD-API], as currently defined, will silently ignore any property not defined in a JSON-LD @context. Implementations that publish Activity Streams 2.0 documents containing extension properties SHOULD provide a @context definition for all extensions.
It is also important to note that there are valid JSON constructs which
cannot be used within a JSON-LD document. For instance, JSON-LD forbids
"arrays of arrays" as used, for example, by the popular
GeoJSON specification. While
implementations are free to use such constructs as extensions within an
Activity Streams 2.0 document, consumers that use the standard JSON-LD
Processing Algorithms will be required to either ignore such extensions
or map those to alternative compatible constructs prior to applying the
JSON-LD algorithms. Simple GeoJSON Points, for instance, can be mapped
to Place
objects, while more complex geometries can be converted to
GeoSparql
"Well-Known Text" representations as illustrated in the non-normative
examples below:
Implementations that parse and then reserialize Activity Streams 2.0 documents that contain extension properties SHOULD take sufficient care to ensure that extension properties used within the original document are preserved and serialized appropriately.
For instance, consider the following simple Activity Stream object
containing hypothetical foo
and bar
extension
properties. The foo
extension is defined within the
JSON-LD @context
while the bar
extension
property is not.
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 only the normative Activity Streams 2.0 context, the JSON-LD compacted form would be:
While this is close, the use of fully expanded URI label for the
foo
property is not ideal. To ensure that the reserialized
object is serialized correctly, implementations that perform JSON-LD
expansion of received documents SHOULD, as much as possible, preserve
the original @context
used when performing the JSON-LD
expansion, then reuse that when reserializing the object into the
JSON-LD compacted form.
Implementations that collect and aggregate Activity Streams objects from multiple sources may often need to deal with conflicting or incompatible extensions.
For instance, an implementation could receive both of the following
objects from clients. In each, a foo
extension property
is defined and used but the definition of each are incompatible:
An implementation that wishes to include both objects within a
Collection serialized into JSON-LD compacted form would face a
number of issues due to the conflicting definitions of the
foo
property. To serialize correctly, the
implementation SHOULD preserve the @context
property
for each of the original objects and include those directly within
the serialized result:
While the serialized result is verbose, the use of the localized
@context
definitions ensures that the conflicting
extension properties will be serialized appropriately.
Many social software systems use special text-based microsyntaxes
that allow users to define special addressing for notifications,
linking, or categorization within objects. For example, including
text such as "@username
" within an object's content
will often route the object to a special "mentions" or "inbox"
stream for a particular user. Likewise, including text such as
"#topic
" within the object's content will often mark
the object as being related to the topic "topic
".
Such mechanisms are commonly referred to as "mentions" and "hashtags",
respectively.
While such microsyntaxes MAY be used within the values of the
content
,
displayName
,
summary
, and
title
properties
on an Activity Streams Object
, implementations
SHOULD NOT be required to parse the values of those properties in order to
determine the appropriate routing of notifications, categorization or
linking between objects. Instead, publishers SHOULD make appropriate use
of the Activity Streams Vocabulary
terms provided specifically for these purposes.
For example, suppose that an author wishes to send a note of thanks to another user named "sally" with a hashtag of "#givingthanks". A typical way this message would appear within the content of a note is shown below:
A typical social software implementation would typically render such a
content such that "@sally
" is replaced with a hyperlink to
"sally"'s social profile page and "#givingthanks
" is
replaced with a hyperlink to a listing of other notes that have been
"tagged" with the same topic. Most implementations would also send a
special notification to sally letting her know that a note mentioning her
has been created.
The following illustrates an equivalent Activity Streams
Note
object:
The to
property indicates that the user "@sally" is
to be considered part of the primary
audience of the note and should therefore receive notification. The
tag
property associates the Note with a reference to
"http://example.org/tags/givingthanks
". Note that the note's
content still includes the "@sally
" and "#givingthanks
"
microsyntaxes but that consuming implementations are not required to parse
those in order to make the appropriate associations.
In the case a publisher wishes to indicate a mention without an associated
notification, the publisher can use the
Mention
object type as a value of the tag
property. The Mention
object is a subclass of
Link
.
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.
Activity Streams are JSON Documents and are subject to the same security considerations described in [RFC7159].
Activity Streams implementations handle URIs. See Section 7 of [RFC3986].
Activity Streams implementations handle IRIs. See Section 8 of [RFC3987].
application/activity+json
Media Type
This specification registers the application/activity+json
MIME Media Type specifically for identifying documents
conforming to the Activity Streams 2.0 format.
Type name: | application |
Subtype name: | activity+json |
Required parameters: | None |
Optional parameters: |
profile: The profile parameter for the application/activity+json
media type allows one or more profile URIs to be specified. These
profile URIs have the identifier semantics defined in [RFC6906].
The "profile" media type parameter MUST be quoted. It contains a
non-empty list of space-separated URIs (the profile URIs).
profile-param = "profile=" profile-value profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <"> profile-URI = URIThe "URI" in the above grammar refers to the "URI" as defined in Section 3 of [RFC3986]. |
Encoding considerations: |
Resources that use the "application/activity+json "
Media Type are required to conform to all of the requirements
for the "application/json " Media Type and are
therefore subject to the same encoding considerations specified
in Section 11 of [RFC7159].
|
Security considerations: | As defined in this specification. |
Contact: | James M Snell <jasnell@gmail.com> |
application/stream+json
Media Type
This specification registers the application/stream+json
MIME Media Type specifically for identifying documents
conforming to the JSON Activity Streams 1.0 [AS1] format.
Type name: | application |
Subtype name: | stream+json |
Required parameters: | None |
Optional parameters: |
profile: The profile parameter for the application/stream+json
media type allows one or more profile URIs to be specified. These
profile URIs have the identifier semantics defined in [RFC6906].
The "profile" media type parameter MUST be quoted. It contains a
non-empty list of space-separated URIs (the profile URIs).
profile-param = "profile=" profile-value profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <"> profile-URI = URIThe "URI" in the above grammar refers to the "URI" as defined in Section 3 of [RFC3986]. |
Encoding considerations: |
Resources that use the "application/stream+json "
Media Type are required to conform to all of the requirements
for the "application/json " Media Type and are
therefore subject to the same encoding considerations specified
in Section 11 of [RFC7159].
|
Security considerations: | As defined in [AS1] |
Contact: | James M Snell <jasnell@gmail.com> |
The author wishes to thank the Activity Streams community and implementers for their support, encouragement, and enthusiasm including but not limited to: 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.
Actor
, OrderedCollection
@id
, url
, self
, etc.mediaType
and rel
properties are defined on Link and not Object.'http://www.test.example/martin' created
'http://example.org/foo.jpg'
. No additional detail is given.
@id
and @type
keywords to express the global identifier and object type:actor
property is considered to be an instance of the Object class while the value of the object
property is
not:Place
and a gr:Location
:Person
and a
vcard:Individual
:Like
and
a http://schema.org/LikeAction
:Collection
,
OrderedCollection
, CollectionPage
, and
OrderedCollectionPage
:
Place
alternative:@context
foo
as an integerfoo
as a date-timeCollection
containing both objects: