Re: Hydra compared with JSON API, other specifications

On 1/12/16 3:24 AM, Tomasz Pluskiewicz wrote:
> Kingsley, Martynas
>
> It seems that your messages stray from the discussion slightly ;)

It doesn't, and here's why: 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.

Anyway, we can move on. These issues will reappear in clearer context,
in due course :)

Kingsley
>
> January 12 2016 2:15 AM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: 
>> On 1/11/16 6:11 PM, Martynas Jusevičius wrote:
>>
>>> First thing I would say that RDF is just part of the graph database
>>> trend. Google uses Knowledge Graph, Microsoft has Office Graph,
>>> Facebook has Open Graph and GraphQL. And there is Neo4J and other
>>> database providers which are growing steadily. RDF is the
>>> best-standardized graph language, so it gets attention whenever graph
>>> data gets attention. Does someone still want to argue graph adoption?
>>>
>>> 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.
>>>
>>> RDF is not for those guys. It is so flexible and simple that their
>>> minds would not comprehend.
> This is harsh, but quite true. However I don't think that RDF and other graph solutions are equal in this regard. Isn't RDF so much more? It's not just a graph data structure and it's where people stumble. And unfortunately it's not the best graph either. Think how cumbersome reification is. And that graphs are not a first class citizen in some areas. Alternatives do one thing and do it good, while RDF seems trying to be too many things at once.
>
>>> 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. Other serializations are perceived as even less friendly. RDF/XML is the common scapegoat, but there are people who don't find Turtle all that great and readable either.
>
>> Yep!
>>
>> 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. Hence I voted for better examples in you poll.
>
>
>


-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this