4 ms·

What's wrong with SPARQL? What advantages has this over SPARQL?

by rambojazz 7y ago

smitty1e 7y ago
SPARQL suffers from Not Invented Here Syndrome.
waffle_ss 7y ago
SPARQL is for RDF data, which not every graph database conforms to.
- namedgraph 7y ago
  And every graph database conforms to Cypher or GQL? These are not even standards, ar least yet.
amirouche 7y ago
SPARQL doesn't allow unbound recursive queries.
baq 7y ago
i can read Cypher having almost zero experience with it, i have no idea what a slightly-more-than-trivial SPARQL query does.
moxious 7y ago
SPARQL is purpose built for the RDF world where you're mixing and matching a zillion different vocabularies, all of which have to be painstakingly declared and name spaced every time. 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.
- staticassertion 7y ago
  I don't suppose you could give me an example that demonstrates the clunkiness? I have not worked with SPARQL myself, but I'm very curious as someone who's been leveraging a graph database (dgraph)
  - namedgraph 7y ago
    I don’t suppose either, because an equivalent example in SPARQL would not be more clunky.
jerven 7y ago
Very few real advantages on a technical level. 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.
- moxious 7y ago
  > Still a more grounded GQL will allow Neo4j competitors to gain on them. Can you expand on this? What do you mean?
  - jerven 7y ago
    Currently it is relatively difficult to move data from one (open)cypher implementation to an other. Also as support is uneven for all features it is not so simple to get started on Neo4J and then evaluate e.g. TigerGraph if you find that Neo4J is not ideal for your usecase. 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.
    - namedgraph 7y ago
      Basically Neo4J thrives on vendor lock-in and standards lower the lock-in.
pimmen 7y ago
SPARQL is not as easy to read. 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.
- jerven 7y ago
  That is more a question of formatting your queries. I can show SPARQL to our data analyst and biologists and they get them. Equivalent Cypher is supper confusing because the queries tend to be quite large and the space between the MATCH and WHERE sections as done in the queries I have seen makes it hard to follow. MATCH (p:Person) WHERE 3 <= p.yearsExp <= 7 RETURN p or PREFIX :<my_bussines_vocab> SELECT ?p WHERE { ?p a :Person ; :yearsExp ?ye . FILTER (3 <= ?ye && ?ye <= 7) } Yes there is a prefix. But if well used they can be super useful. Filter interspersed with the graph pattern helps once the queries get very complicated. 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 or 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' . } The Cypher is difficult in this example because it goes both directions in the linkage, first part is read left to right, second right to left. Making it hard to decompose, and the < or > in the directions are easily missed once the queries get larger. PREFIX :<my_bussines_vocab> SELECT ?pName WHERE { ?j a :Person ; :name 'Jennifer' ; :likes [ a :Technology ; :type 'Graphs'] ; ^:likes ?p . ?p a :Person ; :isFriendsWith ?j } Would be a very close version layout wise to the earlier example from the Cypher tutorial. But I don't think anyone would write that without spending some serious thought about obfuscation ;)
  - baq 7y ago
    FWIW in your second example i was able to understand the Cypher query without so much as a double take and i still don't quite get the SPARQL query. i really have major difficulties a query that would be easier to read in SPARQL than in Cypher.
b3tt3rw0rs3 7y ago
SPARQL requires buy-in into the world of the semantic web even when all you want to do is store and query graph data. 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.
- namedgraph 7y ago
  Not true at all. You can query an RDF dataset with SPARQL and not have any RDFS/OWL schema. A schema/ontology/vocabulary gives you a domain model, but it’s optional.
- namedgraph 7y ago
  Property graphs are mostly popular due to Neo4J marketing enabled by VC dollars. W3C has no such backing.

What's wrong with SPARQL? What advantages has this over SPARQL?

smitty1e 7y ago

SPARQL suffers from Not Invented Here Syndrome.

waffle_ss 7y ago

SPARQL is for RDF data, which not every graph database conforms to.

namedgraph 7y ago
And every graph database conforms to Cypher or GQL? These are not even standards, ar least yet.

amirouche 7y ago

SPARQL doesn't allow unbound recursive queries.

baq 7y ago

i can read Cypher having almost zero experience with it, i have no idea what a slightly-more-than-trivial SPARQL query does.

moxious 7y ago

SPARQL is purpose built for the RDF world where you're mixing and matching a zillion different vocabularies, all of which have to be painstakingly declared and name spaced every time. 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.

staticassertion 7y ago
I don't suppose you could give me an example that demonstrates the clunkiness? I have not worked with SPARQL myself, but I'm very curious as someone who's been leveraging a graph database (dgraph)
- namedgraph 7y ago
  I don’t suppose either, because an equivalent example in SPARQL would not be more clunky.

jerven 7y ago

Very few real advantages on a technical level. 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.

moxious 7y ago
> Still a more grounded GQL will allow Neo4j competitors to gain on them. Can you expand on this? What do you mean?
- jerven 7y ago
  Currently it is relatively difficult to move data from one (open)cypher implementation to an other. Also as support is uneven for all features it is not so simple to get started on Neo4J and then evaluate e.g. TigerGraph if you find that Neo4J is not ideal for your usecase. 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.
  - namedgraph 7y ago
    Basically Neo4J thrives on vendor lock-in and standards lower the lock-in.

pimmen 7y ago

SPARQL is not as easy to read. 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.

jerven 7y ago
That is more a question of formatting your queries. I can show SPARQL to our data analyst and biologists and they get them. Equivalent Cypher is supper confusing because the queries tend to be quite large and the space between the MATCH and WHERE sections as done in the queries I have seen makes it hard to follow. MATCH (p:Person) WHERE 3 <= p.yearsExp <= 7 RETURN p or PREFIX :<my_bussines_vocab> SELECT ?p WHERE { ?p a :Person ; :yearsExp ?ye . FILTER (3 <= ?ye && ?ye <= 7) } Yes there is a prefix. But if well used they can be super useful. Filter interspersed with the graph pattern helps once the queries get very complicated. 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 or 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' . } The Cypher is difficult in this example because it goes both directions in the linkage, first part is read left to right, second right to left. Making it hard to decompose, and the < or > in the directions are easily missed once the queries get larger. PREFIX :<my_bussines_vocab> SELECT ?pName WHERE { ?j a :Person ; :name 'Jennifer' ; :likes [ a :Technology ; :type 'Graphs'] ; ^:likes ?p . ?p a :Person ; :isFriendsWith ?j } Would be a very close version layout wise to the earlier example from the Cypher tutorial. But I don't think anyone would write that without spending some serious thought about obfuscation ;)
- baq 7y ago
  FWIW in your second example i was able to understand the Cypher query without so much as a double take and i still don't quite get the SPARQL query. i really have major difficulties a query that would be easier to read in SPARQL than in Cypher.

b3tt3rw0rs3 7y ago

SPARQL requires buy-in into the world of the semantic web even when all you want to do is store and query graph data. 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.

namedgraph 7y ago
Not true at all. You can query an RDF dataset with SPARQL and not have any RDFS/OWL schema. A schema/ontology/vocabulary gives you a domain model, but it’s optional.
namedgraph 7y ago
Property graphs are mostly popular due to Neo4J marketing enabled by VC dollars. W3C has no such backing.