Re: Activity Proposal Review

Unfortunately, schema.org already has a defined property "actor" for 
movies. It cannot be re-used with a different meaning - even though the 
meanings may have some overlap.

I also find it interesting that schema.org already has a number of 
implied activities, but as nouns, and others as verb-ish phrases. 
schema.org/Movie has "director" and "musicBy", where one might expect 
"composer". So it goes.

kc

On 5/22/13 9:21 AM, James M Snell wrote:
> 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.
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 22 May 2013 18:11:13 UTC