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

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. 

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.

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.


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