Re: Potentials Actions - We Think We're Done

+ jason


On Tue, Apr 8, 2014 at 12:40 PM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> On Monday, April 07, 2014 7:32 PM, Jason Johnson (BING) wrote:
> > The Schema.org team invite final comment review on our latest design
> > for Potential Actions.
> >
> > We think we're done - please take a look.
>
> I'll do a complete review tomorrow (there are so many changes that I'll
> need
> more time) but allow me a first question before I call it a day:
>
>
Thanks Markus! As usual, feedback is greatly appreciated.

This version of the spec
(draft6<https://www.w3.org/wiki/images/2/2d/Potential_Actions_-_Final_Review.pdf>)
should be quite consistent with our last version of the spec
(draft5<https://www.w3.org/wiki/images/2/25/Schemaorg-actions-draft5.pdf>),
albeit IMHO a lot simpler. Most of our focus was to simplify, simplify and
simplify in this revision. A few important changes (some per your
suggestion):

- Moving away from ActionHandlers to Entrypoints. Entrypoints more closely
represents things like APIs and mobile apps, and can be used outside of the
context of Actions too. We are making the distinction based on contentType
and encodingType, rather than the "type of experience they provide" (e.g.
WebPageHandler vs HttpHandler).
- The introduction of the /input and /output property extensions, which
allows us to set constraints on entities in a similar fashion
SupportedClass and SupportedProperties do. It uses the properties of the
Actions as parameters, which I think is helpful to understand what's the
semantic/context of the parameters. I think this is a simpler approach for
webmasters/developers, and there is no loss of expressivity.
- The introduction of url templates and a formalization of how these /input
and /output properties are serialized to GET query parameters as well as
www-form-urlencoding.
- The introduction of ActionStatusType.ActiveAction, to represent actions
that are in progress.

I think the biggest delta in what we are landing today, is the idea of the
target of the action not always necessarily being the resource that it is
attached to. This is indeed a change, but I think it is a good one. We were
having issues modelling things like "adding movies to a watch queue", while
talking about a Movie (since the operation goes to the queue, rather the
movie itself). That issue appears in different situations too, like
ordering coffee (viz restbucks, putting "menu items" to a "shopping cart",
from within the context of the "menu item").



> Why is schema:url use for the target of an operation? It is defined as "URL
> of the item." which is quite ambiguous but I think generally it is used as
> some kind of identifier.
>
>
IMHO, "URL of the item" seems like a reasonable description of what the
Entrypoint is. Whether an entity/resource is in a webpage URL, a mobile app
URL or an API url (whose distinction really just is either the url scheme -
e.g. android-app:// - or the content-type - e.g. text/html vs
application/ld+json- between the two), the pointer to the entity/resource
always goes through the "url" property.


> Why didn't you introduce a separate property such as "target" or
> "targetUrl"?
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>