5 ms·

I'm confused. Isn't SPARQL a query language for RDF? I've used SPARQL extensively against triple stores. It's quite handy and pretty easy to pick up once you

I'm confused. Isn't SPARQL a query language for RDF? I've used SPARQL extensively against triple stores. It's quite handy and pretty easy to pick up once you grok how RDF is structured. I wouldn't even compare it with the concept of RESTful APIs--they're attacking two different problems.

rspeer 9y ago
What were your triple stores running on? A database, right? Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?
- mindcrime 9y ago
  Triple-stores can, but don't necessarily, layer on top of SQL databases. Jena has (had?) a triple-store engine that used JDBC to store the triples in a traditional relational database, but it's been deprecated for years in favor of a specialized engine designed specifically for storing RDF. I can't speak for other triple-stores as Jena is what we use, but I can say that comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos.
  - nl 9y ago
    comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos. In the sense that apples rot and Kangraroos are amazing animals which can do just about anything? Because otherwise the comparison seems completely apt. Jena works for RDF data. But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it. Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves. And if you add the "standardized fields" thing it also matches the REST interface+RDBMS+SQL comparison the OP made.
    - dragonwriter 9y ago
      > But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it. SPARQL is an excellent choice for querying RDF data (SQL is usable but awkward for querying EAV structured data). > Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves. RDF/EAV is more graph than relational structured. It doesn't solve the exact same problem.
      - hipsters_unite 9y ago
        > RDF/EAV is more graph than relational structured. It doesn't solve the exact same problem. Yeah 100% this. Comparing a graph data model and a relational data model while obviously possible isn't really all that fruitful so long as each is being use to solve the problem that they're the best fit for.
        nl 9y ago
        Two points: Firstly: RDF is an inadequate expression of most graphs, and SPARQL is a bad way to query graphs. See my comment here on this: https://news.ycombinator.com/item?id=14603090 https://news.ycombinator.com/item?id=14603090 Secondly: graphs storage is something which is very tempting in theory but very hard to get right in practice. I'm not going to say it is never appropriate (that is clearly untrue), but for most production applications it isn't the right choice. I'd note for example that most social applications use a RDMS to store a single layer of friends (and then perhaps have a second graph DB for batch/stream processing of graph functions).
      - nl 9y ago
        SPARQL is an excellent choice for querying RDF data It's really not! There's a reason why Tinkerpop is what most graph databases standardize on, and why things like Neo4J, DGraph, Caley, TitanDB etc (ie, all the graph DBs which people use when they want to build something and not "do the semantic web") don't use SPARQL.
- lemmsjid 9y ago
  I think we're thinking of different use cases and therefore talking past one another. My SPARQL usage was not using an rdbms under the covers and was explicitly using RDF data. Querying triple data in SQL would be quite clumsy except in the simplest usages, hence the existence of SPARQL. I have seen the libraries that can run SPARQL against an rdbms (for example the 3 or 4 column indexed table that would represent triples or quads). I would imagine performance would be an issue there--but for me rdf has mainly been around aggregating and exploring data, if I need to scale to massive queries per second I'd use something else.
- dragonwriter 9y ago
  > Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database? Probably more efficient, if it's an RDF- (or EAV) oriented datastore underneath, and merely similarly efficient if it's actually layered on top of SQL.

rspeer 9y ago

What were your triple stores running on? A database, right? Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database?

mindcrime 9y ago
Triple-stores can, but don't necessarily, layer on top of SQL databases. Jena has (had?) a triple-store engine that used JDBC to store the triples in a traditional relational database, but it's been deprecated for years in favor of a specialized engine designed specifically for storing RDF. I can't speak for other triple-stores as Jena is what we use, but I can say that comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos.
- nl 9y ago
  comparing SPARQL queries against Jena TDB to SQL queries on MySQL or Postgres is like comparing apples and kangaroos. In the sense that apples rot and Kangraroos are amazing animals which can do just about anything? Because otherwise the comparison seems completely apt. Jena works for RDF data. But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it. Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves. And if you add the "standardized fields" thing it also matches the REST interface+RDBMS+SQL comparison the OP made.
  - dragonwriter 9y ago
    > But the OP is correct in their broader point that RDF is rarely a good choice and SPARQL is a pretty horrible solution for querying it. SPARQL is an excellent choice for querying RDF data (SQL is usable but awkward for querying EAV structured data). > Note that the reply someone is about to write ("But RDF is a generalized self descriptive data model") means it is intended to solve the exact problem that a RDBMS+SQL solves. RDF/EAV is more graph than relational structured. It doesn't solve the exact same problem.
    - hipsters_unite 9y ago
      > RDF/EAV is more graph than relational structured. It doesn't solve the exact same problem. Yeah 100% this. Comparing a graph data model and a relational data model while obviously possible isn't really all that fruitful so long as each is being use to solve the problem that they're the best fit for.
      - nl 9y ago
        Two points: Firstly: RDF is an inadequate expression of most graphs, and SPARQL is a bad way to query graphs. See my comment here on this: https://news.ycombinator.com/item?id=14603090 https://news.ycombinator.com/item?id=14603090 Secondly: graphs storage is something which is very tempting in theory but very hard to get right in practice. I'm not going to say it is never appropriate (that is clearly untrue), but for most production applications it isn't the right choice. I'd note for example that most social applications use a RDMS to store a single layer of friends (and then perhaps have a second graph DB for batch/stream processing of graph functions).
    - nl 9y ago
      SPARQL is an excellent choice for querying RDF data It's really not! There's a reason why Tinkerpop is what most graph databases standardize on, and why things like Neo4J, DGraph, Caley, TitanDB etc (ie, all the graph DBs which people use when they want to build something and not "do the semantic web") don't use SPARQL.
lemmsjid 9y ago
I think we're thinking of different use cases and therefore talking past one another. My SPARQL usage was not using an rdbms under the covers and was explicitly using RDF data. Querying triple data in SQL would be quite clumsy except in the simplest usages, hence the existence of SPARQL. I have seen the libraries that can run SPARQL against an rdbms (for example the 3 or 4 column indexed table that would represent triples or quads). I would imagine performance would be an issue there--but for me rdf has mainly been around aggregating and exploring data, if I need to scale to massive queries per second I'd use something else.
dragonwriter 9y ago
> Do your SPARQL queries turn into anything within orders of magnitude of an efficiently indexed SQL query when they get to the database? Probably more efficient, if it's an RDF- (or EAV) oriented datastore underneath, and merely similarly efficient if it's actually layered on top of SQL.