Re: Implementations without SPARQL

Arthur,

Are you talking about developers who will specify constraints or
developers who would be developing SHACL engines? I believe Holger is
talking about latter and you are talking about former.

Whether the engine is developed using SPARQL or not, does not have any
negative impact on people who are developing constraints. They can still
use SHACL vocabulary to define constraints. If they are not interested or
need to go beyond it, they never get any exposure to SPARQL.

Irene

On 3/24/15, 8:43 PM, "Arthur Ryman" <arthur.ryman@gmail.com> wrote:

>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:50:33 UTC