Re: Hydra compared with JSON API, other specifications

Hi, all.

Sorry for the late followup on this old thread, but it got quite long
quite fast and I only found time to read and respond to everything
now. Please bear with me! :)

2016-01-11 22:42 GMT+01:00 Tomasz Pluskiewicz <tomasz@t-code.pl>:

> Personally the selling point of Hydra+JSON-LD, which differentiates it from
> others like HAL, SIREN, Mason, etc are (in that particular order)
>
> 1. unobtrusive syntax
> 2. expressiveness (and extendability)
> 3. distributed nature
> 4. emphasis on links and metadata
> 5. machine-readability first

I agree!

> This is not strictly related to Hydra, but in my opinion, as a consequence
> of insufficient expressiveness and linking capabilities, there is a general
> tendency to abuse URL structures. Just have a look Swagger sample or RAML.

Oh yes! I absolutely despise those formats for that and a load of
other reasons. :)

2016-01-12 0:11 GMT+01:00 Martynas Jusevičius <martynas@graphity.org>:

> In enterprise IT companies which are far from leading technically, the
> problem is not the obscurity or esotericism of RDF or graphs however.
> It is mismanagement and lack of vision. Left hand not knowing what the
> right hand is doing, miscommunication, non-technical managers and
> architectural astronauts, dozens of non-integrated products with
> overlapping functionality, decades old legacy code and and frameworks
> piled on one each other, rush for more features at the cost of
> technical debt, etc. etc. The R&D department might actually be
> developing something interesting while the management never looks at
> it or chooses to ignore it.

True, true.

> RDF is not for those guys. It is so flexible and simple that their
> minds would not comprehend.

I disagree. If a piece of technology (such as RDF) is unable to
penetrate the market and become ubiquitous, it's not a problem with
the target audience (which for RDF should be "almost every developer
in existence", these days) -- it's a problem with the technology.

For RDF, the problems it has tried to solve, how it's serialized and
how it's marketed (or rather; lack thereof) has been a huge weight
that JSON-LD and its proponents are finally managing to rid it of.

> And JSON(-LD) is a distraction. It's not what matters, it's just a
> format among others, which happens to be well-supported in JavaScript.

I understand how JSON-LD can look like a distraction for someone who's
intimately familiar with RDF and graph theory, but for someone who
just want to publish some data from their SQL Server, it's not. JSON
is a very simple and easy to understand serialization with excellent
tool support. There's almost no developers left in the world who
doesn't know it. That's a quite powerful foundation to build upon.

JSON-LD manages to make RDF integrate into a format in a way where
people don't really need to understand RDF. The fact that the formats
they publish all of a sudden are RDF compatible is an awesome
side-effect they might never discover, it's not why they would choose
it in the first place. In time, this might change; but for now,
JSON-LD (and Hydra) is just an alternative to Siren and the other
formats mentioned in this thread already; a sort of WSDL for RESTful
APIs.

> All notations and serialization formats are distractions in regards to
> the power that RDF provides as a Data Definition Language. Sadly,
> notations and serialization formats have held RDF ransom for more than
> 15 years, amazing!

Indeed! I think the ransom has finally been paid with JSON-LD, though.

> [1] http://osds.openlinksw.com -- Browser Extension that demonstrates
> the high distraction quotient of notation and serialization wars
> [2] https://twitter.com/kidehen/status/685461305495531520 -- Fixing RDF
> Confusion Poll
> [3] https://twitter.com/kidehen/status/684842765277093888 -- RDF Format
> Confusion related Poll
> [4] https://twitter.com/kidehen/status/684425320301228034 --
> Demonstrating the fact that RDF is an Abstract Data Definition Language
> associated with a variety of notations and serialization format.

Great examples!

2016-01-12 2:58 GMT+01:00 Kevin Swiber <kswiber@gmail.com>:

> The comparison of these media types is not very straightforward.  It's not
> just a matter of listing features.  As with everything related to developer
> experience, there's also a "look and feel" component.

I very much agree.

> Speaking in terms of "purity" leads down the path of sounding "too academic"
> for many people.  (It's alienating.)  We've seen this for a long time in the
> hypermedia community.  In the Web API / REST world, we've seen this
> longstanding debate concerning what some people perceive as "purity vs.
> pragmatism."  (For the record, I don't understand how these can be two
> opposing forces.  It doesn't make sense.)

+1!

> JSON API seems to have been an attempt to weave-in hypermedia using an
> easily digestible format.  JSON-LD/Hydra has much more ambitious goals.

Yes. But seeing how the end result for most people will just be a
replication of the browser (but for APIs), I don't think it's
over-ambitious. It will take quite a while to get there, but seeing
how successful the browser is, I think it's obvious that it's possible
to build a similarly intelligent and generic API client.

JSON API can't fulfill these goals. And for that, I'd like to call it
under-ambitious and -- if it becomes sufficiently successful -- a
missed opportunity.

> So based on my experience, here's what I can say:  If your goal is to
> increase adoption of hypermedia within your organization, JSON API or HAL
> will get you there quickly.  If you want to take full advantage of
> hypermedia and effectively model complex interactions, such as workflows,
> Siren or JSON-LD/Hydra can get you there.

In time, I think that the ubiquity of great (and generic) Hydra
clients or client frameworks (libraries on which more specific clients
can be built) will make the case for JSON/LD+Hydra much more
compelling.

> I think we still have many years ahead of us before hypermedia achieves
> widespread adoption.  In the meantime, the landscape is volatile.  You just
> have to choose an option and jump in.  Either start with something simple
> and evolve into a more feature-filled format or start with something that
> seems a little more complex at first but will support your needs for the
> long-term.  It's just a matter of choosing when to invest.

Yep. What's nice about HTTP and conneg is that the choice you make
today does not prohibit you to make a completely different decision in
the future.

2016-01-12 9:24 GMT+01:00 Tomasz Pluskiewicz <tomasz@t-code.pl>:

> January 12 2016 2:15 AM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>
>>> And JSON(-LD) is a distraction. It's not what matters, it's just a
>>> format among others, which happens to be well-supported in JavaScript.
>
> It may be so but at the same time it is finally a piece of RDF stack,
> which gains some adoption. The fact it's "well-supported in JavaScript"
> is a good thing, because it seems more accessible to the average dev.
> From there organizations can discover what RDF really is.

Exactly.

> Other serializations are perceived as even less friendly. RDF/XML is
> the common scapegoat

And for a good reason, imho.

> there are people who don't find Turtle all that great and readable
> either.

Sign me up on that list, please.

>> All notations and serialization formats are distractions in regards to
>> the power that RDF provides as a Data Definition Language. Sadly,
>> notations and serialization formats have held RDF ransom for more than
>> 15 years, amazing!
>
> I agree! Yet JSON-LD is best at introducing people to Linked Data and
> RDF as an extension. And technical documents on the subject have just
> built a wall of apparent "academicness" and complexity.

That's my impression too.

2016-01-12 14:16 GMT+01:00 Martynas Jusevičius <martynas@graphity.org>:

> RDF is much more than graph, you're right. And, just like democracy,
> it's not perfect -- but it's the best we have.
>
> I can also agree about a degree of "academicness". RDF rests on
> well-founded theory, that's why it makes sense and is consistent. But
> theory can be hard, that shouldn't come as a surprise.
> I would not expect an average employee or CS graduate to understand
> the details of the whole suite of OWL or SPARQL specs. I would however
> expect them to understand RDF 1.1 Primer and SPARQL 1.1 Overview.

I'd rather ask why an average employee or CS graduate should need to
understand RDF 1.1 Primer or SPARQL 1.1 Overview. If we set Hydra up
on the premise that these specifications needs to be read and
understood before doing anything fruitful with Hydra, I think it's
going to fail even before it's finished.

> If that is not the case however, than we have a problem. But the
> problem is with education and tunnel-vision, not with the technology.

I disagree, as I've already written above. Let me give you an example:

Monads[1] has been a concept since 1980. They were and probably still
are completely incomprehensible for the average developer. That is,
until you explain to a C# developer that Linq[2] and its
IEnumerable<T> is an almost perfect implementation of a Monadic
structure. So from 1980 and until Linq came along 27 years later,
Monads solved nothing for no one. Linq made Monads approachable and a
way to solve common problems in an accessible programming language a
lot of people use.

While Monads are sound in theory, they had a terrible implementation
for 27 years that made them impossible to understand. The problem was
the technology, not the target audience.

> If CS graduates or even developers or engineers with some years of
> experience can only think in terms of relational databases and
> imperative languages, then this indicates serious holes in their
> knowledge.

True, but the question is how we can and should convey this knowledge.
I think it's possible and important to make the RDF underpinnings of
JSON-LD and Hydra invisible. We need to explain in simple terms what
power JSON-LD+Hydra gives without understanding or caring about RDF.
RDF is a powerful and great side-effect. It is not what will make
people choose JSON-LD+Hydra.

2016-01-12 15:03 GMT+01:00 Kingsley Idehen <kidehen@openlinksw.com>:

> Hydra itself doesn't need to be notation or serialization format
> specific. Its real utility boils down to an ability to describe
> so-called Web Services using abstract language that's comprehensible
> to both humans and machines. Put differently, nothing about Hydra
> really needs to be confined to JSON-LD, RDF-Turle, or any other
> notation or notation/serialization-format combo.

True. And as Hydra is being modeled and designed, I think that's
important to ensure. But without an incredibly intuitive, tasteful,
elegant and KISS format, it's going to be impossible to convey the
strength of Hydra to regular developers. It has to solve simple
problems in simple ways, or else it will just end up solving esoteric
problems for a small and academic audience.

[1] https://en.wikipedia.org/wiki/Monad_(functional_programming)
[2] https://en.wikipedia.org/wiki/Language_Integrated_Query

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

Received on Thursday, 21 January 2016 14:46:37 UTC