Re: Hydra compared with JSON API, other specifications

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.

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



On Tue, Jan 12, 2016 at 9:24 AM, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
> Kingsley, Martynas
>
> It seems that your messages stray from the discussion slightly ;)
>
> 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.
>
>

Received on Tuesday, 12 January 2016 13:16:47 UTC