If I were you I would not deliver that paper. Especially if these are the points you are going to be making.

> JSON-LD is trying to make RDF sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it is just RDF with a new serialization syntax, it share every of its issues.

JSON-LD is _only_ a serialization format. Look, here are _nine_ others. https://help.poolparty.biz/doc/developer-guide/general-infor... Choose the one that best suits your needs. And using language like sexier and pimp, words fail me.

> a literal node (strings which carry the useful information for an human) cannot be the source of an edge, so you end up creating "resources" nodes and pushing content as leaf of the graph. Access to its is thus done with a lot of indirections.

What you mean here is that in the [S, P, O] resource, where S is the subject and P is the predicate and O is the object, one can't make the Subject a string literal. No you can't. Big deal. Whatever language and language framework you're using should have an abstraction for unpacking string literals, and if it doesn't you can roll your own. The semantics of RDF are that literal values are Objects. This is because in natural language we tend to say things like [User5000, is called, "titanix2"] and not ["titanix2", is the name of, User5000]. Sorry if you don't like it, that's the convention: https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

> no annotations, which mean you cannot represent simple graph construct such as a weighted edge.

No idea what this means

> blank nodes, needed to join more than two piece of data which, are anonymous so they are difficult to reuse. That's sad because a graph is supposed to make data link each other. Coupled with issue 1, it mean most linguistic resources graphs are actually closer to trees than real graphs.

I didn't get how blank nodes worked originally and made myself look like a fool when I questioned how they worked on a mailing list. Such is life. They actually make sense for what they do once you wrap your head around them. Rather than me explaining them to you here I urge you consider how they work again: https://www.w3.org/TR/rdf11-concepts/#section-blank-nodes

> reliance on the web infrastructure […]

Well, it's not called the semantic web for nothing! Also, it's been pointed out to me that one can use URNs instead of URLs if you don't want to use the semantics of the HTTP schema. But you know what it seems to be working for pretty much everybody else and how expensive is it to but a domain these days?

> performances is abyssal. I tried one of the dictionary build on RDF, and some query took up to 40 seconds (!) to return no result. Even bloated web dictionaries perform under 2 seconds.

Without further details I'd have to presume you're talking about SPARQL? Yes some queries are slow but if you're dealing with millions or billions of triples then that's inevitable. I've discovered that you can optimize SPARQL once you start digging into it. No it's not easy, but it's not exactly simple tech either. Without details about the triple-store you were querying against and the query you used there's nothing more I can help you with. Anyway, your complaint is like you having a slow query on some particular relational database and you blame the entirety of SQL, wow.