Re: Schema.org Actions - an update and call for review

Thanks Markus for the thoughtful response!


On Thu, Oct 17, 2013 at 12:20 PM, Markus Lanthaler <markus.lanthaler@gmx.net
> wrote:

> On Thursday, October 17, 2013 8:39 PM, Sam Goto wrote:
> > + public-hydra, public-vocabsx
> >
> > That  (moving this thread to the lists) makes a lot of sense to me
> > Markus: adding public-hydra and public-vocabs to log our discussion.
>
> Thanks
>
>
> > Couple of questions:
> >
> > (1) How much benefit are you expecting from the flexibility of
> > supportedProperties? don't you think that that will eventually corner
> > yourself into a fragmented ecosystem of APIs (each having a different set
> > of supportedProperties?)?
>
> As always it depends I would say. Since the supportedProperties are bound
> to
> a class, I don't expect too much fragmentation as I would expect that
> people
> simply reuse the class as a whole in most instance.
>
> As you know, in RDF there's generally no way to tell which properties apply
> to instances of a certain class since the right answer is normally "any"
> (rdf:domain doesn't restrict it). That's why I designed supportedProperties
> in the first place. It mimics the behavior most programmers are familiar
> with.
>
>
> > (2) How are you planning on identifying which
> > specific instances the supportedOperations can act on the
> > supportedClasses? We are running into a problem here that we are calling
> > the "inventory problem": it refers to the fact that the pair "supported
> > operations" (we call these Actions in schema.org) and "supported
> classes"
> > (we call these Things/Nouns in schema.org) isn't sufficient in some
> cases,
> > and you need to take a step further to describe which specific instances
> > your API deals with.
>
> Right. I basically see two solutions depending on the use case...
>
>
> > For example, netflix can stream (http://schema.org/WatchAction) movies
> > (http://schema.org/Movie), but not *any* movie: it can stream a specific
> > set of movies that are in their *inventory* of streamable movies (e.g.
> > movies that in theatres right now are *not* in their inventory, movies
> > that can only be rented via DVDs either, etc).
>
> If there's a large number of instances which all support the same
> operations, it makes sense to create a separate class to communicate that
> information to the client. In the example above, that class could, e.g., be
> called StreamableMovie. The WatchAction can then simply be attached to that
> class. When talking to programmers without Semantic Web background I
> typically explain that in terms of interfaces an instance implements or
> inheritance similar to what they know from their object oriented
> programming
> languages.
>

Although this is in the right direction, we found it to be slightly
trickier than that. One example is that Netflix and Hulu may have
StreamableMovie on their inventories, *but* Netflix/Hulu may only play the
StreamableMovies on *their* inventories.

So, you need to get deeper into the constraint and add that Netflix can
play movies that (a) needs to be a StreamableMovie but as well as (b) it
needs to have url = "netflix.com" for instance.

One direction we are exploring (which adds a *lot* of complexity), is
having some sort of constraint/restriction Type that could express these
constraints. Here<http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-02.pdf>is
one example of such a thing.


>
> If the operations/actions that the various resources of a Web API offer
> widely, it often makes more sense to attach the operations directly to the
> instance instead of binding it to a class. Hydra supports that via its
> "operations" property:
>
> {
>   "@context": "http://purl.org/hydra/core/context.jsonld",
>   "@id": "/a-movie",
>   "title": "A streamable movie",
>   "operations": [
>     {
>       "@type": "http://schema.org/WatchAction",
>       "method": ...
>       ...
>     }
>   ]
> }
>

Yep, that's another direction we are exploring. We are exploring adding one
property to http://schema.org/Thing called potentialAction (or operation,
exact name TBD) that does the mapping to the action that can be taken on a
specific Thing instance.

Here <http://www.w3.org/wiki/images/7/79/Schema.orgActionsMinimaldraft.pdf>is
where we explored this idea.

Basically, instead of expressing the map of action -> entities, we instead
ask publishers/developers to expose the reverse map of entity -> actions
and we then crawl and build the reverse index. Here is an example:

<script type="application/ld+json">

{

 "@context": "http://schema.org",

 "@type": "Movie",

  "url": "http://movies.netflix.com/WiMovie/Like_Crazy/70167118",

"operation": {

 "@type": "WatchAction"

 “status”: “proposed”,

 "handler" : {

    "@type": "WebPageHandler",

    "url": "
http://movies.netflix.com/WiPlayer?movieid=70167118&trkid=1464504&t=Like+Crazy
",

   "method": "GET",

 }

}
</script>


>
>
> > A variation of this problem comes up on a wide range of applications, so
> > much that we need to deal with that as a first class citizen. Here are a
> > few examples:
> >
> > - ticketmaster can "sell events tickets", but specifically upcoming
> > events (e.g. it cannot sell an event that already happened 2 years ago).
>
> This example is in principle the same as the Netflix one above.
>

Agreed, albeit slightly more dynamic than netflix's (that is netflix's
inventory is a bit more static than the ever growing inventory of events).


>
>
> > - opentable can "reserve tables", but specifically to a set of
> > restaurants *and* to specific time slots.
> > - yellowcab can "book cabs", but in specific geographic region.
> >
> > We have a few thoughts on how to address this, but none that we are
> > particularly excited about. Have you run into this problem on hydra?
>
> These two are interesting and highly application-specific. For instance,
> you
> could either model the yellowcab API so that the client first has to find
> the region and before it can order a cab. If it is unable to find the
> desired region it obviously also can't book a cab. An alternative would be
> to send a request to the server containing all the details (route, date,
> time, persons, etc. CabBooking?) and the server then responds with a number
> of options (if there are any). The client then chooses one and books it.
>
> The opentable example could either be solved using a similar approach or by
> exposing all restaurants and available time slots so that the client simply
> has to choose one of the slots and reserve it.
>
> Does that makes sense? What were your ideas regarding these use cases?
>
>
I think you got the general idea of the options we are exploring.

I think the entity -> actions mapping is fairly clear and solves a huge
number of problems.

We still think we need the action -> entities mapping too, we'd love any
input you may have in that area. We explored things like resource
shapes<http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-02.pdf>,
sparql ask queries <http://www.w3.org/TR/rdf-sparql-query/> and prototype
languages <http://en.wikipedia.org/wiki/Prototype-based_programming>.

Here are a few examples (none of which we are particularly excited about):

Resource shapes:

<script type="application/ld+json">

{

 "@context": "http://schema.org",

 "@type": "WatchAction"

 “status”: “proposed”,

 "object/restriction" : {

   "@type": "DataTypeRestriction",

   "describes": "http://schema.org/Movie",

   "property" : {

     "property": "http://schema.org/url",

     "pattern": "http://movies.netflix.com/Movie/",

   }

   "property" : {

     "property": "http://schema.org/streameable",

     "allowedValue": "true",

   }

 },

 "handler" : {

   "@type": "ActionHandler",

   "url": "http://www.netflix.com/watch <http://schema.org/Movie>",

 }

}
</script>

SPARQL


<script type="application/ld+json">

{

 "@context": "http://schema.org",

 "@id": "SFRestaurant"

 "@type": "Type",

 "name": "SF Restaurant",

 "restriction": {

     "@type": "DatatypeRestriction" {

       "sparql": "SELECT ?r WHERE {?r <http://schema.org/address> [<
http://schema.org/addressLocality> 'SF']}"

     }

   }

}

</script>



> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>