SELECT ?cypher_attributes
WHERE {
?cypher a <QueryLanguage> ;
<queries> ?graphs ;
<attributes> ?cypher_attributes .
?user <USES> ?cypher .
FILTER (?user IN ‘Oracle’, ‘Apache Spark’, ‘Tableau’, ‘Structr’)
?opencypher <MAKES_AVAILBLE> ?cypher .
}
Instead of MATCH (cypher:QueryLanguage)-[:QUERIES]->(graphs)
MATCH (cypher)<-[:USES]-(u:User) WHERE u.name IN [‘Oracle’, ‘Apache Spark’, ‘Tableau’, ‘Structr’]
MATCH (openCypher)-[:MAKES_AVAILBLE]->(cypher)
RETURN cypher.attributes
In the SPARQL case the graph flow does not revert on the edge with <USES> (it can using
?cypher ^<USES> ?user, but it would be weird and in the larger queries very confusing). The SPARQL case also tends to group related concepts together.This assumes a DEFAULT BASE URI is selected for the SPARQL version that contains all the modeled relations. Which in a straight comparison to Cypher is a fair comparison.
I find Gremlin a lot nicer than Cypher, and a lot more powerful as well. Also up to today Neo4J just has not scaled all that well. I am awaiting the LDBC Benchmark results of Neo4J to see if I am wrong.
What Neo4J has been great at is making a nice solid product that aims at solving developer problems. I believe as a database it has not been that great at solving enterprise or life science community problems. Its still a single database instance without federation on demand.