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

On Wed, Mar 5, 2014 at 11:48 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> 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?
>
>
So far so good.

A bit concerned about how this will scale long term, but I like the
direction (e.g. it won't corner ourselves, it is useful by itself).


> > - 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?
>
>
Right.

We are considering using AppUrl instead of Deeplink. Does that sound more
descriptive?


>
> > - 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?
>
>
I wanted to emphasize that it needs to be attached to a resource rather
than meant to be used in isolation.


>
> > - 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?
>
>
Can you give an example? Might be more constructive to look at something
concrete.


>
> > - 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.
>

It was originally meant for things like "Adding movies to a netflix queue",
where there is a relationship between two resources: a movie and a queue.

We've removed from this version because it simplifies things. We'll cross
that bridge when we get there.


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

Same here. We'll cross this bridge when we get to it.


>
> 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?
>

I think this is one of the parts that we aren't entirely comfortable yet.
SupportedClass/SupportedProperties are powerful, but seem overly
complicated/nested. I'm exploring a few more options and I'll share them
with you momentarily.


>
> 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
>
>
>