RE: Activity Proposal Review

There is currently a similar issue in MPEG on a discussion on preservation which processes can be compared to actions. It was proposed to use actor, the actor being either an agent (a person/contact ormoral person/organisation) or a tool/software). Actor is hard to use for the same reason as in schema.org. 

The current counter proposal is to have "operator" replacing "actor" as a superclass of Agent and Tool

JP
________________________________________
From: Karen Coyle [kcoyle@kcoyle.net]
Sent: 22 May 2013 20:10
To: public-vocabs@w3.org
Subject: 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

------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

Received on Thursday, 23 May 2013 08:51:57 UTC