- From: Sam Goto <goto@google.com>
- Date: Tue, 8 Apr 2014 23:24:39 -0700
- To: Markus Lanthaler <markus.lanthaler@gmx.net>, Jason Douglas <jasondouglas@google.com>
- Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>, "public-hydra@w3.org" <public-hydra@w3.org>
- Message-ID: <CAMtUnc7BdD-XJqnN=4eMxJtM=ojh=dFBBrE9szMG=0pwgU5_Tg@mail.gmail.com>
+ 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 > > >
Received on Wednesday, 9 April 2014 06:25:12 UTC