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

On Fri Mar 07 2014 at 10:43:52 AM, Markus Lanthaler <
markus.lanthaler@gmx.net> wrote:

> On Friday, March 07, 2014 7:21 PM, Sam Goto wrote:
> > > On Fri, Mar 7, 2014 at 10:11 AM, Markus Lanthaler wrote:
> > > On Friday, March 07, 2014 6:56 PM, Sam Goto wrote:
> > > > On Fri, Mar 7, 2014 at 9:33 AM, Markus Lanthaler wrote:
> > > > > On Friday, March 07, 2014 6:17 PM, Sam Goto wrote:
> > > > > > Yep, we reached the same conclusion here. 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”?
> > > > >
> > > > I think one of the challenges here is that we need to be able to make
> > > > the distinction between APIs to-be-consumed-by-machines (e.g. they
> > > > Accept Content-Type application/ld+json) and human readable pages
> > > > (text/html).
> > > >
> > > > {
> > > >   @type: Movie,
> > > >   alternate: "android-app://com.uber/taxis/1234", "
> http://api.uber.com/taxis/1234"
> > > > }
> > > >
> > > > How would you know that "http://api.uber.com/taxis/1234" is where
> > > > their APIs live? One of the ways around we looked at is to create a
> > > > type:
> > > >
> > > > {
> > > >   @type: Movie,
> > > >   alternate: "android-app://com.uber/taxis/1234",  { @type:
> WebApiUrl,
> > > >     deeplink: "http://api.uber.com/taxis/1234" }
> > > > }
> > >
> > > Yep, but not with deeplink as that wouldn't type the deeplink but the
> > > blank node containing it.
> >
> > Not quite sure I follow this.
>
> You have the following node in the snippet above
>
> {
>   "@type: WebApiUrl",
>   "deeplink": "http://api.uber.com/taxis/1234"
> }
>
> This does *not* type "http://api.uber.com/taxis/1234" as WebApiUrl but
> the anonymous node. To make it clearer
>
> {
>   "@id": "_:blankNode",
>   "@type: WebApiUrl",
>   "deeplink": "http://api.uber.com/taxis/1234"
> }
>
> _:blankNode is of type WebApiUrl.. The type of
> http://api.uber.com/taxis/1234 is unknown.
>
>
> > > > But creating a new property in Thing seemed cleaner. Again, this is
> > > > early enough that we are still debating the trade-offs, but wanted to
> > > > share with you all to gather early feedback.
> > >
> > > If you look at HTML, you'll find typed "alternate" links there. So
> > > it's a proven pattern I'd say. For example:
> > >
> > >   <link rel="alternate" type="application/atom+xml" href="feed.atom">
> > >
> > >
> > > I just found out that Google also uses "alternate" to redirect to
> > > mobile-friendly pages:
> > >
> > >   https://developers.google.com/webmasters/smartphone-sites/
> feature-phones
> >
> > Like I said, the challenge isn't with the mobile-friendly web pages,
> > but making the distinction between human-readable web pages and
> > computer-readable APIs.
>
> And in what regard is that a different problem?
>
>
> > Without apiUrl, the only alternative that
> > comes to mind is the extra type. Just checking: is the following what
> > you are advocating for?
> >
> > {
> >   @type: Movie,
> >   alternate: "android-app://com.uber/taxis/1234", {
> >     @type: WebApiUrl,
> >     url: "http://api.uber.com/taxis/1234"
> >   }
> > }
>
> Exactly, but with @id instead of "url". Unless "url" is just an alias for
> "@id" which I think it should be.


yes, that was the original intent.... not clear whether that's held up
though.  the primary motivation was just that itemid in microdata doesn't
allow you to re-use the href from an anchor tag so it bloats markup.  that
and you can't have multiple values (alternates).

-jason


> We don't know because schema.org still doesn't publish a context. I
> really hope that get's resolved rather sooner than later.
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>