Implementations without SPARQL

May I ask us to take a step back and look at the fundamental questions 
for second? It seems that there is a strange tendency here to turn a 
weakness into a virtue, and that relying on SPARQL is somehow a bad 
thing. Looking at the state of the "market" I am puzzled where this is 
coming from. Let's go through the typical three layers:

Databases
- All commercially successful RDF databases seem to have native SPARQL 
support

Server
- Harold's Python ShEx prototype uses RDFLIB, which has SPARQL support
- Iovka's prototype uses Jena, which has SPARQL support
- Jose's ShEx prototypes are in Scala (a Java VM language) and uses Jena
- Needless to say, TopBraid and RDFUnit use Jena's SPARQL engine too

Client
- Eric's ShEx engine is written against RDF triples, without SPARQL
- IBM have stated they use pure JavaScript, but no details were provided
- However, there are JavaScript libraries for SPARQL too, e.g. rdfstore-js

See also: http://www.w3.org/wiki/SparqlImplementations

So which platforms are left, where a strong point could be made that 
relying on SPARQL is a show stopper? Also, isn't it a normal development 
that most people will simply rely on a 3rd party SHACL implementation 
instead of writing their own? Why would anyone pick a less powerful 
library if a Full implementation also exists?

Let me be very clear that I continue to support the idea of SPARQLless 
implementations, and that many people will not use the SPARQL features 
and we need to cater audiences without SPARQL skills. That's why I 
continue to be in favor of the current partitioning in my draft. Yet I 
am wondering whether some people are unnecessarily throwing out a huge 
number of useful features and use cases only because they don't want to 
rely on SPARQL, for whatever reason. And then based on the 
"we-cannot-rely-on-SPARQL" axiom, the WG may be making ill-informed 
decisions.

Thanks,
Holger

Received on Tuesday, 24 March 2015 22:55:54 UTC