Re: The NoSPARQL use case

Hi Jose,

> On 1 Mar 2015, at 21:19, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
> there is a perception that SPARQL is too low level (this was one of the conclusions from the RDF validation workshop).


The conclusion from the workshop wasn’t that SPARQL is too “low level”. The conclusion was that SPARQL queries cannot easily be inspected and understood, either by human beings or by machines, to uncover the constraints that are to be respected.

A “macro” mechanism that wraps SPARQL queries into named parametrised templates should fully address this particular concern.

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

Yes, SHACL will require more than SPARQL. That’s not a reason to avoid SPARQL in the definition of the language.

> 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 is expressivity. If SHACL doesn’t support highly expressive validation rules, it will be insufficient for the use cases that I care about. I don’t see how this expressivity can be achieved except by allowing the embedding of a highly expressive RDF graph matching language, such as SPARQL. (There are other options beside SPARQL, but SPARQL would be my preference.)

> The advantage of having something that does not depend on SPARQL is portability, performance and usability.

The disadvantage is that it’s not sufficiently expressive.

I am 100% confident that if SHACL won’t have the ability to embed SPARQL (or something of similar expressivity) in version 1, it will fail in the marketplace. The reason is that within six months, it will have multiple incompatible competitors that provide this ability. And the more demanding end of the market (which is most of the market, at the moment) will adopt these competitors, and not SHACL.

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

If SHACL is based on SPARQL-backed “macros”, and provides a well-designed library of “core macros” with known semantics, then implementations are free to optimise validation of the core macros. They could ignore the fact that there’s a “normative” SPARQL template behind these macros, and implement the behaviour of that query in any other way that produces the same results.

So, none of the advantages you cite are incompatible with a SPARQL-centric design.

> And users defining their shapes in one system could employ their shapes in another system. 

That’s the whole point of having a standard.

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

I take it you would object against such a mechanism being a normative part of the language?

> but I think it will be a design language mistake to embed SPARQL in template definitions. 

I still don’t understand why it would be a mistake. Implementations are free to ignore the SPARQL behind the core macros, as long as they produce the same behaviour.

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

Again, the advantage would be that it could address a vastly superior range of use cases.

Best,
Richard

Received on Monday, 2 March 2015 11:08:52 UTC