7 ms·

SPARQL is what happens when you try to define an API for doing everything, from abstract principles, and end up with an API that does nothing. It wraps your da

by rspeer 9y ago

SPARQL is what happens when you try to define an API for doing everything, from abstract principles, and end up with an API that does nothing. It wraps your database in a worse database with a worse query language. It makes simple queries into kilobyte-long GET query strings that get morasses of XML-namespace nonsense as a response, or more likely, a server timeout. While the W3C was screwing around with SPARQL, everyone else came up with JSON-based REST APIs. They work well. Not even the core W3C people use SPARQL anymore.

slaymaker1907 9y ago
You just keep thinking that until you see the god awful mess of REST apis that happens when you need to make an endpoint for every single slightly different query.
- linkmotif 9y ago
  Yeah REST... it's for the truly patient and perseverant. Not to mention the pedantic. "REST principles"—heh. Also: JSON :(. Thank God GraphQL is changing this paradigm and has useable and even powerful clients already. Only bad thing about GraphQL is that it targets JSON but at least it's typed and schematic. But I guess we all benefited from REST, in the sense that it killed the whole 900-page XML book scene which was maybe the worst thing ever.
- rspeer 9y ago
  Yeah, that's kind of how APIs have to work. It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. SPARQL doesn't make it any more feasible, it just ignores feasibility.
  - Vinnl 9y ago
    > It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. GraphQL/Relay and Falcor are trying to make it feasible. And I think it's definitely desirable from a consumer point of view, at least.
  - xg15 9y ago
    > It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. It turns out where and why exactly?
    - rspeer 9y ago
      Denial of service.
      - derefr 9y ago
        You can just 408-response queries after they execute for a given number of CPU cycles. And then rate-limit per-account using evercookies + browser fingerprinting + IP hashing. You can often disallow anonymous queries altogether, while you're at it; if your data is valuable, people are usually willing to register at least a pseudonymous account to get at it.
lemmsjid 9y ago
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
hcarvalhoalves 9y ago
Comparing SPARQL to REST doesn't make sense. RDF is a different beast.
- rspeer 9y ago
  The linked article is describing a world where you encode SPARQL in HTTP query parameters and get back RDF+XML. It really is attempting to be an API for querying everything, but querying nothing well. You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to.
  - mindcrime 9y ago
    You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to. True. It's unfortunate that many people have such a strong mental association with RDF and RDF+XML. The Semantic Web community largely moved on from emphasizing use of RDF+XML something like 10+ years ago, in favor of N3 or Turtle, and - more recently - JSON-LD. But people still hear "Semantic Web" and think "oh, that's that heavy weight XML bloated thing..."
    - zmonx 9y ago
      When I hear "Semantic Web", I think: That's the heavy weight XML bloated thing that has, something like 10+ years ago, moved towards N3 or Turtle, more recently to JSON-LD, and will, in due time, hopefully arrive at Prolog syntax as a very natural and convenient representation that is at the same time amenable for direct processing in a programming language that is eminently well suited for the domain of knowledge representation. Which, I admit, may raise the question why Prolog syntax was not chosen all along, given that its syntax was invented and even standardized decades ago. By the way: A few members of the consortium were well aware that Prolog syntax would have been an excellent choice for RDF. Only a few though.
      - mindcrime 9y ago
        Which, I admit, may raise the question why Prolog syntax was not chosen all along, given that its syntax was invented and even standardized decades ago. By the way: A few members of the consortium were well aware that Prolog syntax would have been an excellent choice for RDF. Only a few though. Good point.
mindcrime 9y ago
We use SPARQL heavily. YMMV. shrug
dragonwriter 9y ago
> It wraps your database in a worse database with a worse query language. SPARQL doesn't necessarily wrap a database with a different underlying query language. And it's a much better query language than SQL for RDF data. > It makes simple queries into kilobyte-long GET query strings Don't do that. I mean, seriously, the protocol supports queries with GET, but it also supports t o different mechanisms for querying over POST. > that get morasses of XML-namespace nonsense as a response SPARQL does not mandate XML responses (for graph responses, it doesn't specify a non-XML serialization, but still on requires RDF/XML or a semantically equivalent structure. For other responses, there are defined JASON, XML, and CSV/TSV formats. > While the W3C was screwing around with SPARQL, everyone else came up with JSON-based REST APIs. SPARQL's defined API is more REST than most of those. > They work well. Not for the purpose SPARQL is aimed at, which is—admittedly—not a particularly common use case, and certainly not what your typical web service needs.

by rspeer 9y ago

slaymaker1907 9y ago

You just keep thinking that until you see the god awful mess of REST apis that happens when you need to make an endpoint for every single slightly different query.

linkmotif 9y ago
Yeah REST... it's for the truly patient and perseverant. Not to mention the pedantic. "REST principles"—heh. Also: JSON :(. Thank God GraphQL is changing this paradigm and has useable and even powerful clients already. Only bad thing about GraphQL is that it targets JSON but at least it's typed and schematic. But I guess we all benefited from REST, in the sense that it killed the whole 900-page XML book scene which was maybe the worst thing ever.
rspeer 9y ago
Yeah, that's kind of how APIs have to work. It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. SPARQL doesn't make it any more feasible, it just ignores feasibility.
- Vinnl 9y ago
  > It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. GraphQL/Relay and Falcor are trying to make it feasible. And I think it's definitely desirable from a consumer point of view, at least.
- xg15 9y ago
  > It turns out it's not feasible or desirable to just let arbitrary people make arbitrary queries. It turns out where and why exactly?
  - rspeer 9y ago
    Denial of service.
    - derefr 9y ago
      You can just 408-response queries after they execute for a given number of CPU cycles. And then rate-limit per-account using evercookies + browser fingerprinting + IP hashing. You can often disallow anonymous queries altogether, while you're at it; if your data is valuable, people are usually willing to register at least a pseudonymous account to get at it.

lemmsjid 9y ago

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

hcarvalhoalves 9y ago

Comparing SPARQL to REST doesn't make sense. RDF is a different beast.

rspeer 9y ago
The linked article is describing a world where you encode SPARQL in HTTP query parameters and get back RDF+XML. It really is attempting to be an API for querying everything, but querying nothing well. You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to.
- mindcrime 9y ago
  You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to. True. It's unfortunate that many people have such a strong mental association with RDF and RDF+XML. The Semantic Web community largely moved on from emphasizing use of RDF+XML something like 10+ years ago, in favor of N3 or Turtle, and - more recently - JSON-LD. But people still hear "Semantic Web" and think "oh, that's that heavy weight XML bloated thing..."
  - zmonx 9y ago
    When I hear "Semantic Web", I think: That's the heavy weight XML bloated thing that has, something like 10+ years ago, moved towards N3 or Turtle, more recently to JSON-LD, and will, in due time, hopefully arrive at Prolog syntax as a very natural and convenient representation that is at the same time amenable for direct processing in a programming language that is eminently well suited for the domain of knowledge representation. Which, I admit, may raise the question why Prolog syntax was not chosen all along, given that its syntax was invented and even standardized decades ago. By the way: A few members of the consortium were well aware that Prolog syntax would have been an excellent choice for RDF. Only a few though.
    - mindcrime 9y ago
      Which, I admit, may raise the question why Prolog syntax was not chosen all along, given that its syntax was invented and even standardized decades ago. By the way: A few members of the consortium were well aware that Prolog syntax would have been an excellent choice for RDF. Only a few though. Good point.

mindcrime 9y ago

We use SPARQL heavily. YMMV. shrug

dragonwriter 9y ago

> It wraps your database in a worse database with a worse query language. SPARQL doesn't necessarily wrap a database with a different underlying query language. And it's a much better query language than SQL for RDF data. > It makes simple queries into kilobyte-long GET query strings Don't do that. I mean, seriously, the protocol supports queries with GET, but it also supports t o different mechanisms for querying over POST. > that get morasses of XML-namespace nonsense as a response SPARQL does not mandate XML responses (for graph responses, it doesn't specify a non-XML serialization, but still on requires RDF/XML or a semantically equivalent structure. For other responses, there are defined JASON, XML, and CSV/TSV formats. > While the W3C was screwing around with SPARQL, everyone else came up with JSON-based REST APIs. SPARQL's defined API is more REST than most of those. > They work well. Not for the purpose SPARQL is aimed at, which is—admittedly—not a particularly common use case, and certainly not what your typical web service needs.