MichelDiz commented :
The biggest challenge with SPARQL. Is that this language was made to support Triple Store databases which follows W3C standards. Dgraph isn’t an RDF Triple Store despite using RDF (in the simplest and most raw format).
IMHO, it’s kind of chaotic having to maintain the support of different languages with different standards and different requirements/needs.
Imagine the chaos it would be to maintain GraphQL, GraphQL+-, Gremlin, Cypher and SPARQL. On each new Dgraph feature would be herculean work to sync. Hard to synchronize. Even if we support just one, so we should abandon GraphQL+- in favor of the new lang (and redesign Dgraph) that we don’t have control (if we add features to Dgraph, we should ask for the lang maintainer to add to that language specs).
I believe it would be easier for you to select the features you like most in SPARQL (or any other) and ask for support in Dgraph than to add another language. Or even suggest changes in the GraphQL+- syntax.
That’s my two cents as a user
BTW, my opinion doesn’t reflects what Dgraph in general thinks.
Extra example of the difference between Dgraph and SPARQL
SPARQL uses “PREFIX” which is linked to the Identifier that is stored in the RDF store format. This Identifier in Dgraph is converted to UIDs. So, to make this to work. It is necessary to sanitize the dataset. Thus, making incompatible with any other RDF stores (means that when you export the RDF you gonna need to revert the sanitize and also you need to rebuild yourself the Identifiers).
Also, the sanitize would need a “hacky” way to the keyword “PREFIX” to work. And one approach should be defined. e.g use dgraph’s type system or edges to represent the PREFIX inside Dgraph.