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

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

From: Sam Goto <goto@google.com>
Date: Thu, 17 Oct 2013 11:38:47 -0700
Message-ID: <CAMtUnc4JQ+yp4OUqsQS-kYSJhez588Ann+=e0DtnZKwpSbVnpQ@mail.gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org, W3C Web Schemas Task Force <public-vocabs@w3.org>
+ public-hydra, public-vocabs

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.

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?)?
(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.

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

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

Sam



On Wed, Oct 9, 2013 at 7:17 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> On Monday, October 07, 2013 10:31 PM, Sam Goto wrote:
> > Can you give me 3-4 canonical examples/scenarios of where
> > you expect hydra to be used?
>
> Not sure I understand that question. It's applicable to basically every Web
> API.
>
>
> > Can you tell me more how you expect
> supportedClasses/supportedProperties/supportedOperations,
> > as well as "expects" and "returns" are meant to be used?
>
> Supported classes is more or less just a helper property to tell a client
> which classes are known to be supported by a specific API. At the moment it
> has no other purpose.
>
> supportedProperties and supportedOperations on the other hand are critical
> concepts. supportedProperties tells a client which properties the API
> supports. So, e.g., if there's an operation that *expects* a Person, it can
> also express what properties of the Person class it supports. Similarly,
> Operations can be associated to classes or properties via
> supportedOperations. You can for example say that if something is of type
> Deleteable it supports a HTTP delete operation to be deleted, or that a
> BlogPost supports a Comment to be POSTed:
>
> {
>   "@context": ...,
>   "@id": "vocab:BlogPost",
>   "title": "A blog post",
>   "supportedOperations": [
>     {
>       "@type": "vocab:CommentOperation",
>       "title": "Comment the blog post ",
>       "method": "POST",
>       "expects": "vocab:Comment"
>     }
>   ]
> }
>
> So, if a client finds data like
>
> {
>   "@context": ...,
>   "@id": "http://api.example.com/1",
>   "@type": "vocab:BlogPost",
>   ...
> }
>
> It will know (well it can find out by derefering vocab:BlogPost) that it
> can
> POST a vocab:Comment to http://api.example.com/1
>
> {
>   "@context": ...,
>   "@id": "vocab:Comment",
>   "@type": "Class",
>   "title": "A blog post comment",
>   "description": "Consists of a subject and body.",
>   "supportedProperties": [
>     {
>       "property": vocab:body",
>       "required": false,
>     },
>     {
>       "property": vocab:body",
>       "required": true,
>     }
>   ]
> }
>
>
> > I'm having a hard time understanding how you'll accomplish adding
> > semantic to web apis with these constructs.
>
> Does the example above clarify it?
>
> Since you are asking great questions, would you mind moving these
> discussions to public-hydra@w3.org or public-vocabs@w3.org? I think a lot
> of
> other people would benefit from our discussion as well.
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
Received on Thursday, 17 October 2013 18:39:14 UTC

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