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

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

> On Friday, March 07, 2014 6:17 PM, Sam Goto wrote:
> On Fri, Mar 7, 2014 at 9:10 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
> wrote:
>
> On Thursday, March 06, 2014 4:38 PM, Sam Goto wrote:
>
> > On Wed, Mar 5, 2014 at 11:48 AM, Markus Lanthaler wrote:
> > > On Tuesday, March 04, 2014 10:27 PM, Sam Goto wrote:
>
> > > > - 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.
>
> So a thing might have multiple urls? Right?
>
> Generally, I have to say that I find the "url" property confusing. It is
> defined as "URL of the item" (http://schema.org/url). Typically, in
> JSON-LD you would just use @id for that. Do you have an explanation of when
> to use what and what it means if both are there?
>
>
>
> > We are considering using AppUrl instead of Deeplink. Does that sound
> > more descriptive?
>
> Yes, it does. It still feels a bit odd though as you type the thing, not
> just the string "android-app://com.netflix/movies/12345". The thing isn't a
> "resource locator" but a "resource".
>
>
>
> Yep, we reached the same conclusion here<http://schema-drafts.appspot.com/ResourceOperation?draft=http://sgo.to/rows/draft6.txt>.
> See this example [1]. The interesting exception are HTTP web apis, which
> have the same scheme as human-readable web pages. Our best take on this so
> far is creating a new property attached to Thing, called Thing.apiUrl [2].
>
>
>
> Hmm... I think I don’t like that at all. So you now have three properties
> to “attach” a IRI to a Thing: @id, url, and apiUrl. That’s two too much
> IMHO. What cause you to retract from “alternate”?
>
>
>

I think one of the challenges here is that we need to be able to make the
distinction between APIs to-be-consumed-by-machines (e.g. they Accept
Content-Type application/ld+json) and human readable pages (text/html).

{
  @type: Movie,
  alternate: "android-app://com.uber/taxis/1234", "
http://api.uber.com/taxis/1234"
}

How would you know that "http://api.uber.com/taxis/1234" is where their
APIs live? One of the ways around we looked at is to create a type:

{
  @type: Movie,
  alternate: "android-app://com.uber/taxis/1234", {@type: WebApiUrl,
deeplink: "http://api.uber.com/taxis/1234"}
}

But creating a new property in Thing seemed cleaner. Again, this is early
enough that we are still debating the trade-offs, but wanted to share with
you all to gather early feedback.


>
>
> A couple of other simplifications that we are exploring: (a) make
> operation take a Class too for subclasses of Action - such that the simple
> use cases for webpage deeplinks remain as simple as possible -,
>
>
>
> Sorry, I can’t parse this sentence.
>
>
>
>
>
> and (b) exploring PropertyRequirement<http://schema-drafts.appspot.com/PropertyRequirement?draft=http://sgo.to/rows/draft6.txt>that is an alternative to SupportedClass (which I know you dislike, but we
> are trying to simplify as much as possible).
>
>
>
> Do you have an example? By just looking at its definition it isn’t clear
> to me how it is supposed to work.
>

I'm working on it as we speak. Will post an update as soon as I have it.
I'll actually post updates on the other thread where we were debating this
very specific subject (just to keep the context clean).

This is still an exploration, but it is towards this direction:

https://developers.google.com/gmail/actions/reference/review-action
http://en.wikipedia.org/wiki/RSDL



>
>
>
>
>
>
> [1]
>
>
>
>
>
> 1. <script type="application/ld+json">
>
> 2.
>
> 3. {
>
> 4.
>
> 5.   "@context": "http://schema.org",
>
> 6.
>
> 7.   "@type": "MusicRecording",
>
> 8.
>
> 9.   "url": "android-app://com.spotify/album/74fjslPVQH60ns7vRlv3tW",
>
> 10.
>
> 11.  "operation": "ListenAction"
>
> 12.
>
> 13.}
>
> 14.
>
> 15.</script>
>
>
>
>
>
> [2]
>
>
>
>
>
> 1. <script type="application/ld+json">
>
> 2.
>
> 3. {
>
> 4.
>
> 5.   "@context": "http://schema.org",
>
> 6.
>
> 7.   "@type": "RentalCarReservation",
>
> 8.
>
> 9.   "apiUrl": "http://api.hertz.com/rentals/honda-crv/reservations/12345"
> ,
>
> 10.
>
> 11.  "operation": "CancelAction"
>
> 12.
>
> 13.}
>
> 14.
>
> 15.</script>
>
>
>
>
>
> > > > - 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.
>
> OK...
>
>
>
> > > > - 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.
>
> I though I did so already.. anyway. Instead of having
>
>   {
>     "@context": "http://schema.org",
>     "@id": "http://example.com/restaurant",
>     "@type": "Restaurant",
>     "ordersBook": {
>       "@id": "http://example.com/restaurant/orders",
>       "operation": {
>         "performs": "CreateAction",
>         "expects": "Order",
>         ...
>       }
>     }
>   }
>
> you would have
>
>   {
>     "@context": "http://schema.org",
>     "@id": "http://example.com/restaurant",
>     "@type": "Restaurant",
>     "ordersBook": {
>       "@id": "http://example.com/restaurant/orders",
>       "operation": {
>         "@type": "CreateAction",  <--- you type the operation itself as
> action
>         "expects": "Order",
>         ...
>       }
>     }
>
> So the operation is at the same time also an action. Which I think makes
> sense. IMO there's no need to add another layer of abstraction (you invoke
> an operation which in turn performs an action). You simply perform an
> operation/action. Operations are thus simply invocable actions.. so a
> specialization therof.
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>