Re: Implementations without SPARQL

Holger,

I believe that Amamitra's point is that the ecosystem of business
partners associated with his product is fluent in JavaScript. They
would not want to learn SPARQL. Therefore a JavaScript implementation
of SPARQL that ran in a browser would not help. This sentiment ties in
with the positive reception for JSON-LD by schema.org adoptors
reported by RV Guha.

There is clearly a new generation of developers who are very
JavaScript-centric. Personally, I think SPARQL is vastly more powerful
and productive than JavaScript for expressing constraints, but many
developers like "monoglot" development in JavaScript. If we appeal to
them, it could make SHACL more impactful.

-- Arthur


On Tue, Mar 24, 2015 at 6:55 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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 Wednesday, 25 March 2015 00:44:20 UTC