Activity Proposal Review

Ok, so I've been going through the current Activity Proposal [1] and
have a few thoughts... (fyi... I'm posting this to both the schema.org
and activity streams mailing lists)

[1] http://www.w3.org/wiki/images/3/38/ActionsinSchema.org2013-05-11.pdf

The proposal largely consists of two distinct concepts:

1. Actions -- A semantic definition of potential activities
2. Activities -- A semantic definition of an action that has been carried out.

These are intended to serve four distinct use cases:

1. Identifying the semantic purpose of web forms
2. Attaching "actional data" to semantic objects
3. Activity confirmation and activity logs
4. Delegation of action execution to other applications.

These, obviously, are all very good use cases and it is great seeing
these being addressed.

First, let's consider the existing Activity Streams spec
(http://activitystrea.ms)

The existing Activity Streams specification is currently targeted only
at use case #3. It provides a simple, extensible JSON format for
describing actions that have been carried out.

The Activity Streams JSON format is intentionally general and
non-specific, opting to provide a minimum of simple, basic properties
and clear extension points so that implementations can at least
perform a minimum level of handling and UI rendering even if it does
not understand the semantics of any specific activity. The format is
not perfect, but it's functional.

Secondary to the core Activity Streams JSON spec, there is an Activity
Streams Schema specification that defines a core collection of verbs,
object types and extension properties. These cover a broad range of
existing real world use cases and clearly demonstrate how the generic
json model can be extended to provide domain specific information.

What is missing from Activity Streams currently, however, is a deep,
rich semantic data model. In order to partially fill that gap, I
introduced a model for blending Activity Streams with external
vocabulary mechanisms like OData, Schema.org and others. Again, this
mechanism is not perfect, but it's functional.

The new proposal for introducing Actions to Schema.org proposes a
mostly identical JSON model with a few key differences...

1. Instead of "verb", it uses "@type"
2. Instead of "actor", it uses "performedBy"
3. Instead of "object", it uses domain specific "extension" properties
associated with the verb/@type
4. It omits the general "target" concept entirely
5. It adds additional common properties that are not currently part of
the core Activity Streams model or that are defined as extensions
(e.g. within the schema spec)

Some of these differences make sense, some do not...

What I would like to do is make a proposal:

First, we can work on a new 2.0 revision of the JSON Activity Streams
specification that defines the core syntax around a JSON-LD
*compatible* model. This model would be very similar to the existing
1.0 syntax but would have a number of important deltas that I can
enumerate later on. The main point, however, is that the syntax would
be compatible with the approach the schema.org activity proposal wants
to take.

Second, the schema.org activity proposal would adopt this updated spec
as it's base as opposed to defining it's own distinct model. That
would mean using "actor" instead of "performedBy" and working with the
Activity Streams Work Group to define and review any necessary basic
format extensions (as opposed to domain-specific stuff which belongs
in schema.org or other places).

The end result would be an updated base Activity Streams model that is
close to the original providing a clear and simple upgrade path for
those who have invested in the current JSON Activity Streams model
while also allowing the new use cases to be met.

Seem like a reasonable approach? I can have an updated first draft
ready to go in about a week.

Received on Wednesday, 22 May 2013 16:22:19 UTC