Should core be unlinked from SPARQL?

[bergos]

In the ticket about sh:pattern, the topic about making the core specification "SPARQL-free" showed up. I think we need to clarify that point.

My understanding was that SPARQL-based constraints or SPARQL-based Node Expression should all go to the SPARQL Extensions specification. I didn't expect that we would get rid of references in the definitions. We should keep them and continue using them to avoid redundancy and diverge.

[VladimirAlexiev]

• I am in favor of removing SPARQL from the Core spec, as a "reference implementation", or even in examples.
  The reason is that SPARQL does not facilitate efficient SHACL implementation since from the point of view of the implementor, it's not declarative.
  As confirmed by @HolgerKnublauch, Node Expressions are more declarative (though SPARQLy things like sh:limit, sh:offset really push the limit on "declarativeness").
• SHACL's Own Profiles #216 discusses that instead of Core vs AF, we need more granular SHACL profiles, eg
  Standard 1.0, with Node Expressions, with SPARQL, ...

[afs]

Somewhere, there should be the SPARQL for every core constraint (non-normative).
I don't mind which document that goes in.

[HolgerKnublauch]

I think we should avoid unnecessary work and duplicate content. When we currently reference SPARQL and doing so avoids redundancies then I would continue to reference SPARQL from Core. We also reference RDF, for example.

@VladimirAlexiev even when it's not declarative, the spec benefits from reusing terminology and definitions from SPARQL. We cannot replace our use of SPARQL with node expressions because that would bootstrap SHACL with itself.

My vote here is to keep things as they are and continue to reference SPARQL.

[bergos]

This is not about SPARQL-based Constraints. The WG agreed to create a separate spec.

SPARQL is used in two different ways in the core specification:

Non-normative SPARQL definition
It's a SPARQL query that shows how a constraint could be implemented in SPARQL. I guess that's what @afs was referring to. I think it makes sense to keep it. Keeping it in the constraint section makes the specification more accessible to people with SPARQL experience. It should stay non-normative.

References to the SPARQL specification
There are references in the SHACL specification, for example, in sh:pattern and sh:flags. I would like to keep it to avoid the mentioned redundancy and the risk of divergence.

[HolgerKnublauch]

Now that I had another look at the Core spec, I no longer have a strong defense for keeping SPARQL for the Core constraint implementations ("Potential definition in SPARQL"). Yes they can add value but they also take up a lot of space and require pulling in terminology from the SHACL-SPARQL spec including pre-binding. It may be easier to keep those out and limit the use of SPARQL to cases like sh:pattern and the <= comparison. This way, I believe, SHACL Core doesn't even need to reference SHACL-SPARQL, which will make the stacking of these documents a bit cleaner.

Given that this is change would be editorial (it is limited to non-normative sections), I'd be happy to create a PR that takes those definitions out and we can then approve or reject it.

(Such a PR would first require someone to approve #258 though)

[afs]

See #235 (comment)

Where would the definitions go to?

The SPARQL forms give the outcome of error conditions e.g. FILTER ($maxExclusive > $value)
(a node expressions issue).

[HolgerKnublauch]

The definitions were only ever informative, so I think we can drop them. If there are new corner cases with node expressions, we need to explain them in the (textual) definition.

[tpluscode]

I don't mind which document that goes in.

Where would the definitions go to?

Maybe we could compile all SHACL <-> SPARQL in a separate non-normative document. That could combine Core, Node Expressions, and possibly others

As confirmed by @HolgerKnublauch, Node Expressions are more declarative (though SPARQLy things like sh:limit, sh:offset really push the limit on "declarativeness").

I personally work on a SHACL-SPARQL conversion using Node Expressions but I still think that Node Expression also should be separated from SPARQL. Even their definitions are agnostic. SPARQL is only used to illustrate. Indeed, the naming of limit/offset does match SPARQL and so does the https://datashapes.org/sparql namespace whose terms can be used as Function Expressions. But on the other hand, the lack of sh:optional is to me proof that it is not the intent to have Node Expressions very closely follow SPARQL.

[bergos]

As the discussion is now only about the non-normative SPARQL definition, do we agree to keep references to the SPARQL specification, like in sh:pattern and all the comparators (sh:minExclusive, sh:maxExclusive)?

Then, I would like to close this issue, and we will continue the discussion on the "Potential definition in SPARQL" on another issue #271.

[HolgerKnublauch]

I have created a PR #294 to move the SPARQL definitions into an appendix of the SHACL-SPARQL spec and will close the ticket here in favor of #271 because the majority of people here seems to be OK with moving the SPARQL queries out of Core and SHACL-SPARQL looks like the perfect place for them.

Please reopen if anyone disagrees.