Re: Hydra Design Goals: How important is RDF?

2015-10-06 9:55 GMT+02:00 Dietrich Schulten <ds@escalon.de>:

> I would like to make it a point that Hydra is very different from the above
> mechanisms in that is not a tool to describe a vendor-specific API and its
> vendor-specific types.

Absolutely. But does that make Hydra unfit to describe vendor-specific
APIs? I don't believe so. I think Hydra easily can replace all of the
mentioned API description mechanisms and bring a lot more long-term
value in both the hypermedia and ontology department. These are values
that aren't as obvious the others I've described, though.

> Rather, its real potential is to describe APIs in such a way that, given a
> common vocabulary, a generic Hydra client can understand the attribute
> semantics and interact with the resources without having to be implemented
> specifically for an API. Schema.org happens to be just such a common
> vocabulary which covers things of interest on the Web.

Yes, this is a great strength, I agree. But I think Hydra is of great
value to people who have never heard the word "ontology" or "taxonomy"
before, just in being a W3C Recommended standard (hopefully) for how
to describe HTTP resources and their hypermedia affordances.

> Opinionated as I am, I would call this the WADL fallacy. Generating API
> clients is as if we would have to generate clients in order to access Web
> pages. This is not how the Web works. In APIs we should do what the browser
> does, or what an Atom client does: it understands the semantics of the
> responses because the media type carries the semantics in itself. Hence you
> can visit web pages and subscribe to feeds *without* reading an API
> description or generate a client first.

As a former member of the IETF Atom Publishing Format and Protocol
Working Group and contributor to RFC 4287 and 5023, I am fully aware
of this. But I think it's important to also be aware of the fact that
most people don't understand this (yet) and that it will take a long
time before we can take this understanding for granted. These are some
of the people we need to cater to:

https://www.mnot.net/blog/2012/04/14/user_personas_for_http_apis

> Json-ld in that regard is the media type that carries commonly agreed
> semantics, defined in public vocabularies like Schema.org and Hydra.

Yes.

> I think it would help a lot if we would build Hydra so that it enables such
> a generic client, maybe use such a client as proof of concept. I plan to
> look into this in the next weeks, is anyone interested and has some time
> left?

I think the Hydra Console is already a pretty great showcase:

http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/api-demo/#

I haven't tried stuffing other Hydra-enabled API's into it, but I
assume that they will work just as well as Markus' demo API.

> Nothing against that, it helps adoption. We would be catering to the
> old-fashioned ways of vendor-specific API descriptions, but hey, that is how
> the API industry works today.

Exactly.

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Tuesday, 6 October 2015 11:39:29 UTC