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

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.


> 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

Received on Friday, 14 February 2014 17:33:53 UTC