W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2014

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Fri, 7 Mar 2014 19:42:20 +0100
To: "'Sam Goto'" <goto@google.com>
Cc: "'Jason Johnson'" <jasjoh@microsoft.com>, "'W3C Web Schemas Task Force'" <public-vocabs@w3.org>, <public-hydra@w3.org>
Message-ID: <013c01cf3a34$f9f9c5c0$eded5140$@lanthaler@gmx.net>
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. 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
Received on Friday, 7 March 2014 18:42:58 UTC

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