SHACLC: grok shaclc-XText and its advanced features
VladimirAlexiev opened this issue · 4 comments
After GuntherRademacher/ebnf-convert#8 was fixed, I was able to process shaclc-XText:
https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html
It's much richer than the other candidate grammars, so @tw-osthus can you help us understand it and list all its features? Does such overview already exist? Maybe you have a report or paper with your proposed additions?
I'll tag not just @jeswr but also @HolgerKnublauch and @afs since some of these ideas seem worthy to do in SHACL as well.
Here's what I was able to see from a quick browse, but I understand no more than half of it:
- shape libraries (versioned). What is the idea with shape libraries?
- imports
- rich targets including SPARQL targets.
- parameterized targets and target shapes?
- rules but unlike SHACL-AF rules that have
subject, property, object, these rules use Construct, and have an "IF" part (being a shape to check) and PRIORITY - function shapes: is this like bringing back SPIN SPARQL functions?
- SPARQL constraints expressed with dedicated syntax (i.e. you don't need to do
"""<sparql query>""") - rich parameter declarations and respective assignments at invocation
- in addition to keywords (eg
xone, xor), use graphical operators (eg><, ⊻, ⩒)
It has been a long time, since I had done it, but I will try to remember
- The idea of shape libraries is to package shapes into libraries, so that we can do a modularized development of shapes. It is used together with the import. A shape library is very similar to an OWL ontology and works technically in the same way. In fact we now use OWL ontology because of inference from owl:import, but there was quite some discussion, whether the assembly of shapes is an ontology in the OWL sense. For any large scale application of SHACL it is a must to modularize and it felt like a serious gap in the specification
- The inclusion of SPARQL were a result that expressiveness of SHACL alone was not enough for the Allotrope use case. We must for example ensure the unique presence of some nodes in an Allotrope file and use the SHACL SPARQL extension for it. If we support SPARQL, it feels natural to also apply it to select targets. Allotrope uses SPARQL sparingly because it is an extension only, so from the view of many of the Allotrope members, not "official" enough.
- function shapes were inspired from SPIN
- 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, if you have a single parser, that ensures consistency
- graphical operators are a way to make it more compact, at the price that you cannot type them (fast) on your keyboard, so I made them optional. The use of well-known operators can help to make the code more readable and I expect like all models that they are far more often read then written, but where the boundary to obscurity ends can be discussed
@tw-osthus Thank you very much for your explanations, this is good text that can provide justifications for such features in a spec.
Can you think of any other features that I've missed?
Have you decided on what complexity the grammar should be?
SPARQL is LL(1), which is simple in tech terms. It is compatible with LALR(1) there are parser generators for every programming ecosystem freely available.
Is there a tool to analyze complexity?
I found only Grammophone but it doesn't support EBNF: mdaines/grammophone#50