Re: Hydra Design Goals: How important is RDF?

2015-10-03 1:44 GMT+02:00 Melvin Carvalho <melvincarvalho@gmail.com>:

> RDF has a reputation of being complex.  But do you actually think it is
> complex.  e.g. compared to OO programming, or C+pointers, or angular JS ...
> or name any number of technologies.  Is complexity really the issue.  Or is
> it fashion?  If RDF became the next big thing everyone wanted to learn, do
> you think there would be a barrier, technically?

I think RDF's biggest problem thus far has been incomprehensible
syntax. I think that with JSON-LD, we finally have something that has
great value without the proposition of RDF (i.e. being able to
identify links in JSON), that the value and understanding of RDF can
take off. Finally. :-)

> I dont think serialization is unimportant.  I doubt anyone said that.

No one has said that explicitly. But matters related to serialization
has been waved off with "developers can just map that with JSON-LD",
which most developers won't understand how to do. Which brings me back
to the point of having a great, intuitive and user friendly default
serialization with JSON-LD.

> Turtle is probably more readable than JSON LD

I strongly disagree, but that's of course because I've read a few
gigabytes of JSON and only a few bytes of Turtle. I do, however,
expect most HTTP API developers to be in my boat, where JSON is what
their eyes have been exposed to and everything else will look alien,
strange and ultimately; incomprehensible.

> again we have the fashion problem, of course XML was the fashion of its day.

Yes, it's absolutely related to fashion. But I think what's in fashion
is important to acknowledge. 10 years ago, it was XML (and
unfortunately, RDF/XML was horrible), today it's JSON (and JSON-LD is
quite beautiful imho).

> But is there much point in doing hydra without having a universal data model
> to map to?

I'd say a huge and roaring: Yes! For many people, I expect Hydra to
"just" be an alternative to HAL[1], Siren[2], API Blueprint[3],
Swagger[4], Slate[5], etc. The fact that it is powered by RDF will be
a (very) nice bonus, but probably not something that will be the huge
sell. For many, I expect the RDF part of it is something that will be
discovered long after Hydra has been chosen as the format in which to
describe their HTTP APIs.

> Whats the value add, compared with just documenting APIs in the
> old fashioned way?

What I experience most people having issues with when coming from
HTTP/REST alternatives like SOAP, is the lack of a service description
(WSDL) from which they can get an auto-generated and statically typed
client from. While hypermedia does not fit great with static typing,
having a service description that a client can be automatically
created from, is extremely valuable. A default Hydra to AngularJS[6]
or Aurelia[7] interface generator would not only not be unthinkable,
but extremely powerful.

A service description is also a great basis for auto-generated
documentation. It's not hard to envision a default Hydra to Slate, API
Blueprint or Swagger converter, for instance.

> So are you suggesting the mandatory serialization of the RDF used is JSON
> LD, or to underplay RDF altogether?

I'm not suggesting to underplay RDF. Not by any stretch of the imagination.

> If JSON LD is mandatory, should other serializations be excluded.  Or
> something different.

I'm not sure. Perhaps JSON-LD should be mandated. All up until this
discussion, I didn't even think of alternative serializations. And I
do think that alternative serializations will make Hydra and the APIs
using it less accessible.

>> I'm not saying we should swap out RDF. I'm just saying; let's not let
>> the RDF aspects of Hydra overshadow all design decisions, causing the
>> end result to be unintelligible for people who don't know or
>> understand RDF.
>
> Im curious how this would work, some kind of RDF lite, or something invented
> from scratch.  I wonder if you wouldnt end up reinventing the wheel.  This
> could be an interesting proposal tho.

I don't think we need an alternative to RDF, I just think that
whenever there's a decision to be made regarding serialization, let's
make sure a decision is made to improve the legibility of the
serialization so it ends up as accessible, intuitive and user friendly
as possible. If not, Hydra will be a harder sell, even though at the
RDF level, it is unimportant.

____
[1] http://stateless.co/hal_specification.html
[2] https://github.com/kevinswiber/siren
[3] https://apiblueprint.org/
[4] http://swagger.io/
[5] https://github.com/tripit/slate
[6] https://angularjs.org/
[7] http://aurelia.io/

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

Received on Monday, 5 October 2015 09:45:30 UTC