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, b

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).