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

> On 3 Mar 2015, at 14:45, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
> On Tue, Mar 3, 2015 at 1:06 PM, Irene Polikoff <irene@topquadrant.com> wrote:
>> <Because "SPARQL queries cannot easily be inspected and understood, either by human beings or by machines, to uncover the constraints that are to be respected". [1]>
>> 
>> I believe this has already been addressed by SHACL.
> 
> Not if we don't have a set of well defined constructs with a clear semantics and we limit SHACL to have a single "template" construct where we can put any SPARQL code. 

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]

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

Received on Tuesday, 3 March 2015 15:36:24 UTC