should we bring back explicit RDF-based SPARQL syntax?

[VladimirAlexiev]

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

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?