What's wrong with SPARQL? What advantages has this over SPARQL?
Practically, the PG model has many syntactic advantages over the equivalence in expression power RDF+reification. (See excitement over RDF*, which is can be pure syntactic sugar) Syntax is important for usability.
I don't believe that PG in Cypher or GQL will be significantly more expressive than SPARQL 1.1. And in any case are quite different from the tinkerpop model.
I believe it is essential for Neo4J as a growing company that they move beyond their own Cypher to something that is more defined and critically allows them to check a "we are a standard" box on big deals. OpenCypher has solid adoption but lacks coherence between implementations. i.e. same data same query, different result.
Still a more grounded GQL will allow Neo4j competitors to gain on them.
Can you expand on this? What do you mean?
If your application only uses GQL then you could start on Neo4J but after two years in production cheaply move to a competitor. By just switching your backend and run your test cases etc. your data did not change, your queries remain the same, so evaluation is relatively straightforward.
I see this quite often in the SPARQL world. First few years of a product is with engine A, then some annoyance in production show up. Engines B-D are evaluated and a different one is chosen. Or sometimes both are run at once for different query workloads on the same data. Which is relatively cheap in the SPARQL environment. But because of custom engineering in the property graph world to move from engine 1 to engine 2 it is much more expensive in engineering hours.
For most of us working not on the "semantic web", we typically only have 1-2 vocabularies, which is our data model, and SPARQL is super clunky to use.
Also, property graphs wouldn't have managed to get the traction they have if SPARQL would have been sufficient. SPARQL simply suffers from being designed in a way that does not sufficiently address the needs of application developers, in expressivity, ease of use, let alone allowing easy migration of existing relational data by sharing the same type system with SQL.
I can show SQL or Cypher to some of my product managers who have experience with Excel, and they actually sort of get it. That’s not the case with SPARQL.
MATCH (p:Person)
WHERE 3 <= p.yearsExp <= 7
RETURN p
PREFIX :<my_bussines_vocab>
SELECT ?p
WHERE { ?p a :Person ;
:yearsExp ?ye .
FILTER (3 <= ?ye && ?ye <= 7)
}
I have never seen a real study of Cypher being easier to read than equivalently well formatted Sparql.
MATCH (j:Person {name: 'Jennifer'})-[:LIKES]->(:Technology {type: 'Graphs'})<-[:LIKES]-(p:Person),
(j)-[:IS_FRIENDS_WITH]-(p)
RETURN p.name
PREFIX :<my_bussines_vocab>
SELECT ?pName
WHERE {
?j a :Person ;
:name 'Jenifer' ;
:likes ?graphTech .
?p a :Person ;
:name ?pName ;
:likes ?graphTech ;
:isFriendsWith ?s .
?graphTech a :Technology ;
:type 'Graphs' .
}
PREFIX :<my_bussines_vocab>
SELECT ?pName
WHERE { ?j a :Person ; :name 'Jennifer' ; :likes [ a :Technology ; :type 'Graphs'] ; ^:likes ?p .
?p a :Person ; :isFriendsWith ?j }
i really have major difficulties a query that would be easier to read in SPARQL than in Cypher.
The SPARQL is more paragraph based. We are looking for ?j a :Person named 'Jenifer' and ?p a person who is a friend of ?j . Both need to be interested in graph technology.
This kind of sections of defining a query ends up easier when the relations are multitude between nodes. e.g. friends, colleagues and past having non identical lunch preferences.