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

On Fri, Feb 14, 2014 at 9:33 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> On Friday, February 14, 2014 1:48 AM, Sam Goto wrote:
> > Breaking up the thread here to have a more focused conversation.
>
> Good idea.
>
>
> > So, you originally wrote:
> >
> > ============================================================
> >
> > Kind of. What I was trying to do is to remove the whole ActionHandler
> > stuff. I don't want there to be "endpoints" which I can use to invoke
> > the operation. In my world view, operations are executed on the
> > resource. In other words, operations describe the things you can do
> > with a resource, not where you can send the resource to. In the
> > optimal case, there wouldn't be a need to describe Android intent
> > handlers as Android would be able to recognize the resource and its
> > operations and then figure out which locally installed app can handle
> > that combination. That's, however, too ambitious at the moment. Thus
> > we probably need an alternative for the time being. One option would
> > be (as I mentioned to you in another mail) to separately describe Web
> > resources and "app resources".
> >
> > To be a bit clearer: What I have in mind is to link from the Web
> > resource to the app, similar to how App Indexing for Google Search
> > works:
> >
> > https://developers.google.com/app-indexing/webmasters/details
> >
> > So, a simple example would look like this:
> >
> > {
> >   "@context": "http://schema.org",
> >   "@id": "http://example.com/web/resource",
> >   "operation": ... operations supported by the web resource ...
> >   ...
> >   "alternate": {
> >     "@id": "android-app://com.package/android/resource",
> >     "@type": "AndroidAppLink",
> >      ...
> >      "operation": ... possible but not necessary IMO ...
> >   }
> > }
> >
> > I simply reused App Indexing's "alternate" link relation here but
> > appLink or perhaps even sameAs could work just as well. Obviously you
> > can further describe that Android resource.
> >
> > Does this make it any clearer?
> > ============================================================
> >
> > Lets explore this a bit more. If I understand you correctly, here is
> > what a resource (that can be found in different platforms) would look
> > like:
> >
> > {
> >   "@context": "http://schema.org",
> >   "@id": "http://example.com/web/resource",
> >   "operation": [{
> >     @type: ViewAction
> >   }, {
> >     @type: BuyAction
> >   }]
> >   "alternate": [{
> >     "@id": "android-app://com.package/android/resource",
> >     "@type": "AndroidAppLink",
> >   }, {
> >     "@id":
> "msApplication://microsoft.build.App/resource?arg1=1,arg2=2,etc",
> >     "@type": "WindowsAppLink",
> >   }, {
> >     "@id": "myapp.com://resource?arg1=1,arg2=2",
> >     "@type": "iOSAppLink",
> >   }, {
> >     "@id": "https://www.googleapis.com/example/v3/examples/resourceid",
> >     "@type": "ApiAppLink",
> >   },]
> > }
> >
> > Few questions:
> >
> > 1) Microsoft Windows resources can only be reached if the user has a
> > "minimum version" of the app installed. How do you deal with that?
> > Where does the minVersion information goes?
>
> I think you could simply add it to the WindowsAppLink. Of course, in the
> optimal case it would be reflected in directly in the URL (scheme) but
> annotating that resource would be fine as well I think, you could say that
> resource "requiresMinVersion":
>
>    }, {
>      "@id":
> "msApplication://microsoft.build.App/resource?arg1=1,arg2=2,etc",
>      "@type": "WindowsAppLink",
>      "requiresMinVersion": "2.0"
>    }, {
>
> Alternatively, and probably better, would be to include that information
> in the operations associated to these resources. See below.
>
>
> > 2) How would you be able to express that you CANNOT BuyAction on the
> > AndroidAppLink resource (e.g. your mobile app resource isn't as fancy
> > as your website)?
>
> That's something we would need to decide. I think in most cases these
> resources are not really exactly the same. Thus, I'm not sure whether it
> makes that much sense to "inherit" the operations from the Web resource. I
> think it would be sensible to require them to be declared separately. I
> don't think "expects" etc. are needed for apps, are they? If not, it's
> really just a short list of supported operations similar to the one in your
> example above, likely with min. version constraints etc.
>

Not quite on both points.

1) Most often than not, these are the same resources. That's the basic
premise of the android-app://foobar.com/resource/1234 with rel=alternative
links.
2) "expects" apply to apps as much as web resources. as you are "buying" an
item on the web or in an app, things like your credit card / quantity
information needs to be passed either way. that is, i'd expect to see
things like http://amazon.com/products/1234?action=buy&quantity=2 as much
as things like android-app://com.amazon/products/1234 with
putExtra("quantity", "2") in the intent extra bag.


>
>
> > 3) Developers have the ability to specify "how" to execute the HTTP
> > call (e.g. pick a specific parameter encoding). How do we go about
> > that without the ActionHandler?
>
> The model above describes the operations a resource (the target resource)
> supports. As such, I think that information belongs directly into the
> operation. We had some discussions about this in the context of Hydra but I
> don't have a concrete proposal yet. Generally, it's not as trivial as it
> looks, e.g., in Actions in Gmail at the moment. You need, e.g., to define a
> mapping from an (RDF) graph to a list of key-value pairs as used with
> application/x-www-form-urlencoded. As far as I understood it, Actions in
> Gmail currently just use the property (path) and omit the
> http://schema.org/ prefix, right?
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>