RE: ActionHandlers vs "App resources" (was: An updated draft of the schema.org/Action proposal)

On Tuesday, March 04, 2014 10:27 PM, Sam Goto wrote:
> 
> A co-worker and I went over some of these points yesterday.
> 
> Here is a *preliminary* build with the ideas we went over here written
> down:
> 
> - In this *test* build, we remove the concept of ActionHandler.

And, how do you find that?


> - As a replacement, we instead allow Thing.url to point us to
>   platform-specific Deeplink (e.g. AndroidDeeplink, ApiDeeplink and
>   WindowsDeeplink)

OK, so, e.g., you have a Movie (the abstract thing) which points via the "url" property to a representation thereof in an Android app. Right?


> - Without ActionHandlers, it felt awkward to have things like
>   expects/returns in the Action types, so we've created a specific
>   type to carry these service-y information, called ResourceOperation
>   where expects/returns live.

Great. So you basically came to same conclusion we came in Hydra. There it also lives on Operation. I don't care too much but why do you call that thing ResourceOperation instead of just Operation? I mean, isn't everything a resource?


> - The semantics of the operation are still dictated by the Action
>   types, via performsAction attached to ResourceOperation.

Any specific reason why you don't simply type an operation with the corresponding action?


> - That also allows us to remove ActionStatus, leaving the Action
>   subtypes to carry past-actions-like semantics

Oh I see. Was that the reason? Couldn't you simply say that Operation-Actions are "possible actions" instead. That would save you some nesting.


>   and ResourceOperation
>   to take advantage of the Action sub-type's semantics on proposed
>   actions.
> 
> WDYT?

Looks quite good to me. The only thing I don't like that much is the *deeplink terminology but I could live with that.  A couple more questions:

ResourceOperation has a property "destinationResource". I'm not entirely sure I understand what it is for or why it would be needed.

The same applies to "supportedPlatform". Isn't that already described by AndroidDeeplink etc.?

SupportedProperty has a property "supportedClass". What's the use case for that? I.e., why do you need to link back from a SupportedProperty to its class?

Shouldn't "SupportedClass" be a subclass of "Class" instead of "Intangible"



> On Tue, Mar 4, 2014 at 7:30 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> On Monday, March 03, 2014 11:40 PM, Sam Goto wrote:
> > On Mon, Mar 3, 2014 at 10:34 AM, Markus Lanthaler wrote:
> > > On Monday, March 03, 2014 7:11 PM, Sam Goto wrote:
> > > > On Mon, Mar 3, 2014 at 9:36 AM, Markus Lanthaler wrote:
> > > > > You'd have specific action handlers attached to the action. Example
> > > > > (of a Movie that can be "watched" on android and "bought" via a
> > > > > webpage):
> > > > >
> > > > > {
> > > > > @type: Movie
> > > > > action: [{
> > > > >   @type: WatchAction
> > > > >   handler: {
> > > > >     @type: AndroidHandler
> > > > >   }
> > > > > }, {
> > > > >   @type: BuyAction
> > > > >    handler: {
> > > > >      @type: WebPageHandler
> > > > >   }
> > > > > }
> > > > > ]
> > > > > }
> > > > >
> > > > > How would we go about this using sameAs/alternate?
> > > >
> > > > You would use a very similar pattern (adapting your previous example):
> > > >
> > > > {
> > > >  "@context": "http://schema.org",
> > > >  "@id": "http://example.com/web/resource",
> > > >  "alternate": [ {
> > > >      "@type": "AndroidAppLink",
> > > >      "operation": {
> > > >        "@type": "WatchAction"
> > > >    }, {
> > > >      "@type": "ApiLink",
> > > >      "operation": {
> > > >        "@type": "BuyAction"
> > > >    }
> > > >  ]
> > > > }
> > > >
> > > > Hum ... this doesn't seem right to me ... I wasn't expecting actions to
> > > > be attached to these "Links", since there is a difference between
> > > > "watching" a movie and "watching" a link.
> > >
> > > Right, I just reused your terminology to show the pattern. I wouldn't
> > > call those things *Link as a link is an arc between two resources and
> > > not a single resource as these things here are. Would it look better
> > > to you if you would replace, e.g. AndroidAppLink with
> > > AndroidAppResource?
> >
> > That's still a bit awkward. You'd want to have a WatchAction attached
> > to a Movie, rather than a generic AndroidAppResource (which may refer
> > to any type).
> Can't it be both at the same time? I hope we are not heading down the httpRange-14 path now :-)
> 
> 
> 
> Cheers,
> Markus


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 5 March 2014 19:48:59 UTC