W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 17 Oct 2013 21:20:00 +0200
To: "'Sam Goto'" <goto@google.com>, <public-hydra@w3.org>, "'W3C Web Schemas Task Force'" <public-vocabs@w3.org>
Message-ID: <046101cecb6d$e10d44a0$a327cde0$@lanthaler@gmx.net>
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.

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
Received on Thursday, 17 October 2013 19:20:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC