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

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

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


[1]


   1. <script type="application/ld+json">
   2. {
   3.   "@context": "http://schema.org",
   4.   "@type": "MusicRecording",
   5.   "url": "android-app://com.spotify/album/74fjslPVQH60ns7vRlv3tW",
   6.   "operation": "ListenAction"
   7. }
   8. </script>



[2]


   1. <script type="application/ld+json">
   2. {
   3.   "@context": "http://schema.org",
   4.   "@type": "RentalCarReservation",
   5.   "apiUrl": "http://api.hertz.com/rentals/honda-crv/reservations/12345
   ",
   6.   "operation": "CancelAction"
   7. }
   8. </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
>
>
>
>