11–20 of 53 posts
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, ever…
Are there queries that SPARQL can perform over a triplestore that cannot be done with SQL over normalized data? Perhaps not. But data normalization to that end is a moving target, while a bag of subject-predicate-object statements are quite doable. This, I believe, is a uniquely powerful characteristic of linked data / graph query languages and protocols. To that end, agree with the comment above that GraphQL is migh…
GraphQL, though, is a bit of a lie nomenclature-wise. As I've experienced it, it's got nothing much to do with graphs, at least not in the sense that SPARQL deals with triples that form a graph. In this department I am really interested in TinkerPop [0]. I would love, some day, to spend some more time with triple stores, RDF and semantic technologies. [0] http://tinkerpop.apache.org/docs/current/reference/
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, ever…
Comparing SPARQL to REST doesn't make sense. RDF is a different beast.
You can write reasonable REST APIs for RDF. You can even formalize it with JSON-LD if you care to.
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, ever…
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.
SPARQL is not an API framework as much as it is a query language. Many powerful graph databases are queried via SPARQL.
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, ever…
Nothing makes me happier than seeing the semantic web hit the front page. Too bad most people don't understand it.
My feeling is, the Semantic Web vision is still growing and still permeating it's way through things. I think it's taken longer than probably anybody expected, but it's an ambitious-as-fuck-all idea too, so that should hardly be surprising.
The thing is, in this fad-driven industry, once something slips off the hype wagon, and isn't "cool" or "sexy" anymore, it's something of a struggle to get people interested. Everybody is all "ooooooh, shiny!" and off to chase the javascript framework du jour.
Nothing makes me happier than seeing the semantic web hit the front page. Too bad most people don't understand it.
Earlier quoted context omitted.
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.
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?
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.
Earlier quoted context omitted.
Comparing SPARQL to REST doesn't make sense. RDF is a different beast.
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.
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..."