
SPARQL Protocol for RDF - mindcrime
https://www.w3.org/TR/rdf-sparql-protocol/
======
rspeer
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
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.

~~~
rspeer
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.

~~~
xg15
> _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
Denial of service.

~~~
derefr
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.

------
jerven
I love SPARQL, although I often say it causes problems for developers but
solves problems for organizations.

I know I am not in the average developer sphere, but working as a data
provider to the wider public (ok scientific public) SPARQL is fantastic. First
is that classic rest+json give data but do not allow analytics. Second is that
SPARQL has federation. While CPU time wise it is inefficient for scientists
its saves them months trying to get a local copy of the db setup.

SPARQL implementations are reasonably efficient and certainly do not need to
be less efficient than SQL stores (even if they often are). However, as it is
a query language not an implementation it can behave completely different.
i.e. it can have great K/V performance with relatively poor analytics e.g.
Marklogic or Oracle NoSQL SPARQL. or poor K/V perf but good analytic e.g.
virtuoso or Oracle Semnet on its RDBMS. You can switch implementation and have
completely different performance characteristics without needing to redo your
data model etc...

As lead developer for the public facing rest and sparql endpoints of the
UniProt consortium I know which is cheaper to run, SPARQL by an order of
magnitude even if it uses more hardware.

Even inside the consortium developers who should have easy access to our SQL
databases use our public SPARQL endpoint because it is easier to do so. That
includes developers who have been writing SQL for decades and are not afraid
of an explain plan. Opening a webpage is just quicker than getting SQL
developer started and requires a whole lot less of tunneling.

Also a 1.5Tb on disk database such as sparql.uniprot.org is not going to be
fun in all cases. The equivalent spread over the different production SQL
databases is no fun either and no smaller (in this case actually federated
until recently with oracle links, now some are postgres).

------
miguelrochefort
Nothing makes me happier than seeing the semantic web hit the front page.

Too bad most people don't understand it.

~~~
mindcrime
Same here. Honestly though, I'm surprised. I submitted this even though it's
kinda old, because I was reading up on federated SPARQL queries, and had a
random thought that somebody might find it interesting. I didn't actually
expect any significant number of upvotes, or for this to make the front-page.

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.

------
dnt404-1
Anybody can share some light on companies that uses semantic web technologies?
Currently at university have a semantic web class but I am finding it
difficult where the use case are to create value for business or startup.

~~~
tannhaeuser
Facebook Open Graph crawlers use RDF in HTML head-meta elements conveying data
about authors of web pages.

Similarly, Google Corporate Contacts extracts RDF from web pages (but can also
use JSON microdata).

W3C's newly published open social standard is based on RDF (as JSON-LD) I
believe.

RDF and SPARQL has lots of uses in libraries and bibliographic apps such as
citation managers, as well as in publication of open data, in particular
medical and bio informatics data.

Dublin Core (as RDF) is frequently used for standard document metadata, for
example in PDF.

~~~
hsivonen
Does Facebook now actually do RDFa-compliant processing for OGP? Back when OGP
was introduced they didn't. [https://lists.w3.org/Archives/Public/www-
archive/2011Apr/006...](https://lists.w3.org/Archives/Public/www-
archive/2011Apr/0062.html)

------
lolive
One of the benefit of SPARQL is that you can extract a subset of a given
dataset as RDF. And can inject it into another RDF graph.

Eventually, you can build-up your dataset by picking subsets of other
datasets, and link your own data graph with all that.

(The top of the top is to use SPARQL federated query, so you can do all that a
query-time).

If you consider SPARQL as a way to implement REST API, it is the most flexible
API a data producer can provide: you can run whatever query on my dataset, I
force nothing.

What I see as a failure in the SPARQL ecosystem, it is the lack of SPARQL
query repositories for all public datasets.

I tried to develop a tool for that (cf datao.net) but it never took off.

------
ghukill
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 mighty exciting.

~~~
linkmotif
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/](http://tinkerpop.apache.org/docs/current/reference/)

~~~
handojin
You might really enjoy datomic (www.datomic.com). Everything is stored as
entity attribute value time and you query with a dialect of datalog. You can
check out www.learndatalogtoday.org to get a flavor.

~~~
tannhaeuser
Datomic, though, isn't Datalog syntax at all.

I've got nothing against Datomic, but can't help to think learndatalogtoday is
outright false advertising by trying to capture "Datalog" as SEO term for a
proprietary graph database which has nothing to do with Datalog/Prolog.

The point of Datalog is that it's a subset of Prolog syntax, implying that
engines can be reasonably exchanged for one another. But this is only possible
with real Datalog, or SPARQL for that matter.

------
anon1253
For those who like to know a conceptually a bit more about RDF/Sparql:
[https://joelkuiper.eu/semantic-web](https://joelkuiper.eu/semantic-web)

Bonus: my SPARQL Clojure wrapper
[https://github.com/joelkuiper/yesparql](https://github.com/joelkuiper/yesparql)

------
mfrager
SPARQL is not an API framework as much as it is a query language. Many
powerful graph databases are queried via SPARQL.

~~~
rspeer
As a feature to put on a checklist, not as the way they expect you to use
them. Powerful graph databases generally have to come up with their own query
languages.

