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

On Friday, March 07, 2014 6:17 PM, Sam Goto wrote:
On Fri, Mar 7, 2014 at 9:10 AM, Markus Lanthaler < <mailto:markus.lanthaler@gmx.net> 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”?

 

 

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  <http://schema-drafts.appspot.com/PropertyRequirement?draft=http://sgo.to/rows/draft6.txt> PropertyRequirement 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.

 

 

 

[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