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

>
> 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. You also obtain
compatibility between shapes defined in those different systems and you can
even do some reasoning about shapes like comparing if two shapes describe
the same RDF graph.

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

What is more, this proposal is even compatible with your proposal, because
you can implement the high level language using SPARQL + mumble
mumble...There is no advantage of limiting SHACL to work only on top of
SPARQL.

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.

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