Re: “SHACL Minus SPARQL” (was: Re: On the inevitability of SPARQL/SPIN for SHAQL)

Hi Jose,

> On 3 Mar 2015, at 20:43, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
>> But this is a false alternative. The proposal is to have all of the above:
>> 
>> - A single “template” construct that allows the definition of “macros”
>> - A well thought out library of “core macros” with clear semantics
>> - [mumble mumble something about recursion]
>> 
> My proposal is just the opposite...you may call it "SHACL plus  SPARQL" if you like:
> 
> - A single high level language that contains the common constructs for RDF validation and has a well defined semantics independent of SPARQL
> - Some extensibility mechanisms that allows users to express complex constraints in SPARQL (or other external language)
> - Optionally, some construct to define macros if the WG considers them necessary.
> 
> The main advantage is that you obtain a high level language which can be optimized and implemented by different technologies.

The claim that this is an advantage of “SHACL Plus SPARQL” is false. The “SHACL Minus SPARQL” profile can also be optimised and implemented by different technologies.

> You also obtain compatibility between shapes defined in those different systems

The claim that this is an advantage of “SHACL Plus SPARQL” is false. Shapes defined in the “SHACL Minus SPARQL” profile would also be compatible between such different systems.

> and you can even do some reasoning about shapes like comparing if two shapes describe the same RDF graph.

I am not aware that this is a requirement that this working group has embraced.

> This alternative does not depend on a particular technology (SPARQL + mumble mumble something about recursion) and offers more advantages.

The claim that the “SHACL Minus SPARQL” profile depends on a particular technology is false. It can be implemented without SPARQL.

I believe that “mumble mumble something about recursion” is, at the moment, a shared feature between both proposals.

> What is more, this proposal is even compatible with your proposal, because you can implement the high level language using SPARQL + mumble mumble…


The “SHACL Plus SPARQL” proposal is not compatible with the “SHACL Minus SPARQL” proposal, because the latter proposal offers users of the “SHACL Full” language the ability to create SPARQL-based macros, while the former proposal doesn’t.

> There is no advantage of limiting SHACL to work only on top of SPARQL. 

The claim that the “SHACL Minus SPARQL” profile works only on top of SPARQL is false. The profile can work on any underlying technology provided that a semantics-preserving mapping to SPARQL is available.

> I repeat that I have no problem to define the semantics of the high level language with mappings to SPARQL, but we should be able to identify that high-level language so we can allow other systems to implement it.

In “SHACL Minus SPARQL”, the high-level language is the library of “core macros”. I’d be delighted to work on nailing down this set of core features, but this is rather difficult as long as one party to the discussion is in denial about what the other party is saying.

I take the liberty to again add a link to my proposal:
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0059.html

If you don’t understand the proposal, then that’s my fault for being too brief or too nebulous, and I am happy to explain and expand, but I need questions to know where to start.

Best,
Richard






> 
> Best regards, Jose Labra
> 
> 
> -
> 
> Most SHACL authors would use the “core macros”. Many SHACL authors may be unaware that there are “templates” behind the macros, or that they can define their own macros. To them, SHACL would appear as a 100% “high-level language”.
> 
> Some implementations may only support the “core macros”, and may not support the creation of custom “user macros”, or the direct embedding of SPARQL. Such implementations would not require a SPARQL engine at all.
> 
> Some SHACL implementations may ignore the “templates” behind the core macros, and may instead use other, more efficient, evaluation strategies to arrive at the same, well-defined results.
> 
> There could be a profile — I will call it “SHACL Minus SPARQL” here — that consists of *just* the “core macros”. It could be fully implemented without a SPARQL engine, and its semantics could be described in any formalism, as long as that formalism can be cleanly mapped to the SPARQL templates behind the core macros.
> 
> This proposal seems to address all your objections. It has a high-level language. Its semantics can be cleanly defined in alternative formalisms. It is implementable without SPARQL (if one is not interested in advanced constraints, extensibility, and future-proofness).
> 
> If I’m not mistaken, the only difference between this and your proposal (which allows for SPARQL as extensions anyway) seems to be that this proposal allows for user-defined macros that expand to SPARQL. Are there any other differences that I have missed? I don’t understand why you consider user-defined macros so harmful. You’ve tried to explain it via analogies with Assembler, but they didn’t click for me.
> 
> Best,
> Richard
> 
> 
> 
> -- 
> -- Jose Labra

Received on Tuesday, 3 March 2015 21:20:46 UTC