Re: Hydra Design Goals: How important is RDF?

On 5 October 2015 at 11:44, Asbjørn Ulsberg <asbjorn@ulsberg.no> wrote:

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

So are you saying to use JSON LD in a specific readable way?  If so, that
makes sense, could it be achieved through examples?


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

Turtle is designed to be readable.  I dont think there's right or wrong to
this one, just personal preference and familiarity.


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

OK, I think we agree :)


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

Thanks for the pointers to these APIs, they do look well presented.

Are you saying you'd like to see some kind of Hydra Lite that is targeted
at JS developers that are not familiar with other things?

I really dont know if this would work or not, it's hard to evaluate the
utility, but it may be worth considering.

My concern here is that you'd freeze out those that did want to work with
RDF, so would there be an upgrade path.


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

OK, im intrigued enough to want to know more.  How would it look?  Who do
you think would work on it etc.


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

So what about working on a JSON LD context for some syntactic sugar?


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

Totally agree that legibility is of great importance to adoption and the
links you've shared demonstrate that.  I find your arguments reasonable,
but must admit im not 100% sure what you're proposing.  Personally I'd be
willing to listen tho!


>
> ____
> [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»
>