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

Just backtracking a little bit on my recursion tree here :) We've talked a
bit about point (2), but let me ask you a few more questions about point
(1).


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

Right. We are running into a similar problem too. I'm having two
philosophical debates:

(I) is this a good idea? will it corner ourselves in the future?
(II) assuming this is a good idea, which constructs do we use to model it?

A few points on topic (I):

(a) will this cause API fragmentation?
(b) how do we deal with backwards compatibility ? e.g. once you published
an ApiDocumentation, and clients are using it, you can not add a
SupportedProperty that is *required* without breaking existing clients
prior to an API migration.
(c) how do you keep your clients in sync with your ApiDocumentation? When
you make "SupportedProperty requirements" changes to your ApiDocumentation,
how do clients become aware?

A few questions on point (II):

(a) have you looked into resource
shapes<http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-02.pdf>
?
(b) have you considered SPARQL ASK queries?
(c) have you tried concepts from prototype languages?


>
>
> > (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.
>
> 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": ...
>       ...
>     }
>   ]
> }
>
>
> > 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.
>
>
> > - 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?
>
>
> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>