Re: Actions in Schema.org - Potential vs Performed Actions

Hi Jim,
Answers below.

On Thu, May 16, 2013 at 3:46 PM, Jim Klo <jim.klo@sri.com> wrote:

>
> On May 16, 2013, at 12:18 PM, Yaar Schnitman <yaar@google.com> wrote:
>
> Jim, your raised the issed that "potential" actions and "performed"
> actions on a Thing are hard to distinguish.
>
> The proposal suggests using the Action.status property just for that, and
> specifies that the Thing.action should be for "potential" actions only. You
> are right however that the status might be omitted and the action property
> misused, leading to ambiguity.
>
> I think that one simple solution for that would be to have instead two
> properties on Thing:
>  * Thing.potentialAction (or tentativeAction, to match with the
> corresponding ActionStatus value) - an action that can be potentially
> performed on the Thing. Repeated values will mean that multiple actions are
> supported.
>  * Thing.performedAction - an action that was performed on the Thing in
> the past. Repeated values will form an "activity stream" for the Thing.
>
> What do you think?
>
> -Yaar
>
>
> Seems like a reasonable approach IMO.   It certainly makes sense if you
> consider some context where you have both "potential" and "performed"
> actions at the same time.  I like it much more in comparison to having a
> property named "action" and Class named "Action" - which in itself becomes
> confusing (And as Dan pointed out earlier, he's got a straw-man to build
> around this).
>
> The only thing (which is just syntax) that I might quibble over is
> property names… I might prefer availableAction over potentialAction
> (tenativeAction makes a lot of sense too) but I don't have any real strong
> opinion either way.
>
Yeh, potential makes more sense.

>
> As a personal preference, if the property naming convention could use
> "action" as a prefix, such that the rest of the name might be the
> discriminator, like Available, Performed… the properties would naturally
> 'sort' together, like "actionAvailable", "actionPerformed" versus other
> proposals - which would keep the properties together within documentation,
> reducing risk of misuse.  I know it's a quirky way of looking at this, but
> my experience tells me that if you keep similar attributes of things named
> well such that they collate, I see less misuse because a developer didn't
> bother to use a scroll bar.
>
This is a good idea actually. I'll work this into the draft.


>
> The leading question however is, should the inverse be done as well?
>  Should Action have appropriate properties to delineate the "item" the
> Action is "performedOn" or "tenativeFor"? Or do we leave "status" as the
> trigger indicator?  In the context of Thing, as discussed above - I think
> Action.status is more likely to be omitted, however where Action is the
> primary element, it might be more realistic to expect an Action.status
> property.
>
Action doesn't have a "target" property, such as "item". Instead,
sub-actions have more precise, verb-specific properties. For instance,
RsvpAction has the "event" property, and BuyAction has the "itemBought"
property. Note that "bought" is the passive form of "buy", not the past
form of "buy", so can be used for potential actions as well.

I don't know if Action.status would be less likely to be omitted when the
Action is the primary element. I think search engines / user agents should
standardize what the default is in such case. I think its should be
"Performed". I'll add that to the draft.


>
>
>  *
> Jim Klo
> Senior Software Engineer
> Center for Software Engineering
> SRI International
> *
> *
> t. @nsomnac
>
> *
>