consider embedding SPARQL syntax in SHACL-C

[VladimirAlexiev]

@HolgerKnublauch, @tw-osthus, @jeswr
(Last item of #199)

Allotrope's SHACLC.xtext proposes Dedicated Syntax for SPARQL constraints and rules, i.e. unlike SHACL SPARQL, SPARQL is not embedded in RDF literals ("""<sparql query>""") .

@tw-osthus lists the following advantages, which I agree with;

• Having a syntax for SPARQL allows a much better integration.
• We do not have a language within a language.
• XText (and other grammar based code generators) can be used to directly generate code from it, and it is so much more powerful to have consistency ensured by a single parser.

I only see one minor disadvantage:

• Copies large parts of the SPARQL grammar, which is in flux because of SPARQL-star and SPARQL-dev. But so what, when SPARQL grammar changes, this part of SHACL-C grammar can also change.

We have 2 ways of implementing this SHACL-C syntax to SHACL:

• Compile to triples (use a target RDF representation for this dedicated syntax). There was SPIN SPARQL Syntax (RDF triple constructs for expressing SPARQL queries), which afaik, SHACL abandoned because it was too wordy.
  • Disadvantage:
    • Need to devise two algorithms: "SHACL parsing and compilation to triples" and "generation of SPARQL from triples"
  • Potential benefit:
    • Using an explicit SPARQL representation gives a better chance of implementing incremental evaluation.
    • Roughly speaking; if you know the triple patterns checked, you can watch for these triple patterns and not invoke all SPARQL constraints and rules on every repository change
    • If the SPARQL is embedded in strings, you need to parse this into some data structure and extract the triple patterns from it
• Implement as text
  • Benefit: this is simpler

Overall, I think we don't need to do this. Or it can be a lower-priority feature to be tackled in SHACL 1.3 or later.
What do others think?

[HolgerKnublauch]

I suggest closing this ticket as Node Expressions will cover similar use cases and already has an RDF syntax. The WG isn't big enough to create a dedicated SPARQL syntax, nor is it in really in scope here.

Agree @VladimirAlexiev ?

[VladimirAlexiev]

Hi @HolgerKnublauch!

WG isn't big enough to create a dedicated SPARQL syntax

SPARQL syntax exists already.
This issue is about embedding it in SHACL-C: not as strings but as a sub-grammar.
But the title "explicit RDF-based SPARQL syntax" is very confusing: I've now changed it.

I agree that Node Expressions overlap in purpose with SPARQL.
But Node Expressions won't exile SPARQL from SHACL, right?
If so, then this issue is valid.

[jeswr]

My read is that the issue is valid, but I also agree with the statement "Overall, I think we don't need to do this. Or it can be a lower-priority feature to be tackled in SHACL 1.3 or later."

[afs]

We need a syntax for node expressions, subject to #352.

All SPARQL expression functions can be called by URI so there is a way to call SPARQL functions and functional forms without special syntax.

[VladimirAlexiev]

@afs @HolgerKnublauch
Will SHACL 1.2 evict SPARQL? And replace it completely with node expressions?