Re: The NoSPARQL use case

On Sun, Mar 1, 2015 at 12:35 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> Hi Eric, hi Jose,
>
> Both of you have said that SHACL should be implementable without having
> access to a SPARQL engine.
>
> I’d like to understand what motivates this requirement.
>
> Can you expand on this? What are the positive consequences for our various
> users (SHACL document authors, SHACL implementers, end users of products
> that support SHACL, etc.) that would result from being able to implement
> SHACL without having a SPARQL engine?
>
> If this has been discussed or written up in the past before I joined the
> WG, then I apologise and would be grateful for a pointer.
>
> Thanks,
> Richard


>From my point of view, one of the already approved requirements is to
define a high level language because there is a perception that SPARQL is
too low level (this was one of the conclusions from the RDF validation
workshop).

Defining a high level language means that one can identify which are the
constructs of that language. That's why I think we need an abstract syntax.

One you have identified the language constructs you have to implement them.
SPARQL by itself is not enough as it doesn't handle, for example, recursion
so there is a need for something else.

Apart from that, I have already said that I have no problem to have
mappings to SPARQL and even to include them in the spec. But what I would
like to know, is why should we design something that depends on SPARQL when
there is an alternative to define something that can be independently
implemented? What is the advantage of limiting it to only be implemented in
SPARQL?

The advantage of having something that does not depend on SPARQL is
portability, performance and usability. Of course, the Shacl language can
be defined with mappings to SPARQL, but I am sure that there could appear
other tools implemented in other languages which would improve the
performance of the implementation and its usability. Those tools can
improve error messages and offer optimizations that otherwise could not be
done. And users defining their shapes in one system could employ their
shapes in another system.

As I said in another thread, I am really not opposed to have extensibility
mechanism that can call SPARQL and I also think we can have some
implementation in SPARQL, but I think it will be a design language mistake
to embed SPARQL in template definitions.

On the other hand, I don't see any advantage of limiting the implementation
of SHACL to be only in SPARQL.

-- 
-- Jose Labra