- From: Sam Goto <goto@google.com>
- Date: Fri, 14 Feb 2014 10:11:07 -0800
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: Jason Johnson <jasjoh@microsoft.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>, public-hydra@w3.org
- Message-ID: <CAMtUnc7kJa=JX5sQRwQCJFQZfJktXXkTBbCZ4fNn-ppzk1SmUA@mail.gmail.com>
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 > >
Received on Friday, 14 February 2014 18:11:41 UTC