From 05dcd21b6527852b0e5bc81d5dec83f18ffa9132 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Fri, 2 Aug 2024 14:47:21 +0300 Subject: [PATCH 01/15] add features and implementations --- shacl-compact-syntax/scope.md | 50 ++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 13 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 0f5c96e..bd0bc8b 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -18,15 +18,28 @@ Note that this should be done *after* these features have been supported by the ## New Features -### Support for additional SHACL-C shorthands - - Support Rules - - Support (SPARQL) Functions - - Support shorthand (`<`, `=`, `<=`, etc.) for property pair constraints - - [Support `xone` and more `or` cases](https://github.com/w3c/shacl/issues/12) - - Opting out of the production of the triple `?baseUri rdf:type owl:Ontology` - - Support for non-validating characteristics (e.g., generating `sh:order` triples by declaring `@order` at the top of a file/shape, allow grouping by `@group` at the top of a set of properties, and allowing a `@description` above properties). +### Support for Additional SHACL-C Constructs +- shorthand (`<`, `=`, `<=`, etc.) for property pair constraints +- [Support `xone` and more `or` cases](https://github.com/w3c/shacl/issues/12) +- Opt out of the production of the triple `?baseUri rdf:type owl:Ontology` +- Non-validating characteristics (e.g., generating `sh:order` triples by declaring `@order` at the top of a file/shape, allow grouping by `@group` at the top of a set of properties, and allowing a `@description` above properties). +- Target shapes, see [rsx:targetShape](https://rdf4j.org/shacl/extensions.html) -The first 2 of these have been supported in [this xtext file](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [allotrope](https://www.allotrope.org/). Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. +A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [Allotrope](https://www.allotrope.org/): +- [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. It is used together with 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. +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 +- [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) +- Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. +- [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) +- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape) but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) Construct, and have an "IF" part (being a shape to check) and PRIORITY +- [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions +- Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation +- [SPARQL Constraints](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) expressed with a dedicated syntax (i.e. you don't need to do `""""""`) +- [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (eg `><, ⊻, ⩒`) in addition to keywords (eg `xone, xor`) + +Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. ### [Making SHACL-C Lossless](https://github.com/w3c/shacl/issues/36) @@ -34,7 +47,7 @@ There are attempts to implement lossless SHACL-C by allowing the use of a more T - [Extended Compact Syntax in `shaclcjs`](https://github.com/jeswr/shaclcjs?tab=readme-ov-file#extended-shacl-compact-syntax) - [make SHACL-C→SHACL nearly lossless TopQuadrant/shacl#98](https://github.com/TopQuadrant/shacl/issues/98) (escape into Turtle, and some extra links and ideas) -### Extending the test suite +## Extending the Test Suite There is also work that can be done to make the test suite more robust such as: - [SHACL-C: missing property shape TopQuadrant/shacl#142](https://github.com/TopQuadrant/shacl/issues/142) (test case) @@ -42,10 +55,21 @@ There is also work that can be done to make the test suite more robust such as: - [SHACL conversion: malformed lists TopQuadrant/shacl#92](https://github.com/TopQuadrant/shacl/issues/92) (test case) ## Implementations -The current SHACL-C implementations include - - https://jena.apache.org/documentation/shacl/#shacl-compact-syntax - - https://github.com/jeswr/shaclcjs and https://github.com/jeswr/shaclc-writer - - https://gitlab.com/allotrope-open-source/shape-editor +Current SHACL-C implementations include the following. + +Parsers/writers (i.e. convertors between SHACL and SHACL-C) + - TopQuadrant had a SHACL-C implementation that is deprecated in favor of Jena's. + The the current SHACL-C specification [cites the grammar](https://w3c.github.io/shacl/shacl-compact-syntax/#grammar-section) of this implementation + - [Jena](https://jena.apache.org/documentation/shacl/#shacl-compact-syntax): implemented in Java + - [allotrope-open-source/shape-editor](https://gitlab.com/allotrope-open-source/shape-editor): implemented in Java for the Eclipse framework (uses XTEXT). + Introduces a number of number of new SHACL-C Constructs (see https://github.com/w3c/shacl/issues/52 ), reflected above + - [jeswr/shaclcjs](https://github.com/jeswr/shaclcjs) and [jeswr/shaclc-writer](https://github.com/jeswr/shaclc-writer): implemented in JavaScript + - [edmondchuc/shaclc](https://github.com/edmondchuc/shaclc): implemented in Python, also has a [playground](https://edmondchuc.github.io/shaclc/) + +Editing helpers: +- [jeswr/shaclc-language-server](https://github.com/jeswr/shaclc-language-server): Language Server, implements intellisense features for modern IDEs like VS-Code +- [VladimirAlexiev/shaclc-mode](https://github.com/VladimirAlexiev/shaclc-mode): for Emacs, implements syntax checking and highlighting, jumping from reference to definition + ## Related Issues - [SHACL-compact-syntax #7](https://github.com/w3c/shacl/issues/7) From dcb7cd7aec594604a158b2f34e77d9724d36b6f9 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Fri, 2 Aug 2024 14:52:17 +0300 Subject: [PATCH 02/15] fixes --- shacl-compact-syntax/scope.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index bd0bc8b..4f8793a 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -26,18 +26,27 @@ Note that this should be done *after* these features have been supported by the - Target shapes, see [rsx:targetShape](https://rdf4j.org/shacl/extensions.html) A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [Allotrope](https://www.allotrope.org/): -- [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. It is used together with 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. -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 +- [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. + It is used together with 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. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) - Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. + 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. - [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) - [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape) but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) Construct, and have an "IF" part (being a shape to check) and PRIORITY - [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation -- [SPARQL Constraints](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) expressed with a dedicated syntax (i.e. you don't need to do `""""""`) -- [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (eg `><, ⊻, ⩒`) in addition to keywords (eg `xone, xor`) +- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. you don't need to do `""""""`. + 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](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (eg `><, ⊻, ⩒`) in addition to keywords (eg `xone, xor`). + It is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable and we expect that like all models, they are far more often read then written, but where the boundary to obscurity ends can be discussed Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. From 8d2adedc125b78db2b3bc9062c7783ecfdcf2b70 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:11:49 +0300 Subject: [PATCH 03/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 4f8793a..8640d1e 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -28,9 +28,9 @@ Note that this should be done *after* these features have been supported by the A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [Allotrope](https://www.allotrope.org/): - [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. It is used together with 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. + A shape library is very similar to an OWL ontology and technically works in the same way. + In fact, we now use OWL ontologies because of inference from `owl:import`, but there was quite some discussion about whether the assembly of shapes is an ontology in the OWL sense. + For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) - Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. The inclusion of SPARQL were a result that expressiveness of SHACL alone was not enough for the Allotrope use case. From a2722a1fa0d0595549bc183db98f67fe63493e2c Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:12:19 +0300 Subject: [PATCH 04/15] add link to Import Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 8640d1e..513ecd4 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -27,7 +27,7 @@ Note that this should be done *after* these features have been supported by the A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [Allotrope](https://www.allotrope.org/): - [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. - It is used together with Import. + It is used together with [Import](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl). A shape library is very similar to an OWL ontology and technically works in the same way. In fact, we now use OWL ontologies because of inference from `owl:import`, but there was quite some discussion about whether the assembly of shapes is an ontology in the OWL sense. For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. From 1381d2590d4ac9c030abc5742425b1194def2f36 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:12:47 +0300 Subject: [PATCH 05/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 513ecd4..f9d5b71 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -38,7 +38,7 @@ A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-sourc 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. - [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) -- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape) but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) Construct, and have an "IF" part (being a shape to check) and PRIORITY +- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape), but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, and have `IF` (being a shape to check) and `PRIORITY` parts - [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation - [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. you don't need to do `""""""`. From eb65b4a3810ce1f1f9ce36c80a4b98abbc559848 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:13:39 +0300 Subject: [PATCH 06/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index f9d5b71..9a293ef 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -45,8 +45,8 @@ A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-sourc 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](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (eg `><, ⊻, ⩒`) in addition to keywords (eg `xone, xor`). - It is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable and we expect that like all models, they are far more often read then written, but where the boundary to obscurity ends can be discussed +- [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (e.g., `><`, `⊻`, and/or `⩒`) in addition to keywords (e.g., `xone` and/or `xor`). + This is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable, and we expect that, like all models, they are far more often read then written, but where the boundary of obscurity ends is open to discussion. Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. From 458aab6acca74e49c52ae050f58cd9f7f1e5c12b Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:13:57 +0300 Subject: [PATCH 07/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 9a293ef..0162475 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -64,7 +64,7 @@ There is also work that can be done to make the test suite more robust such as: - [SHACL conversion: malformed lists TopQuadrant/shacl#92](https://github.com/TopQuadrant/shacl/issues/92) (test case) ## Implementations -Current SHACL-C implementations include the following. +Current SHACL-C implementations include those listed below. Parsers/writers (i.e. convertors between SHACL and SHACL-C) - TopQuadrant had a SHACL-C implementation that is deprecated in favor of Jena's. From 5024cae572aac6983905d05e8519f88665dd6282 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:14:27 +0300 Subject: [PATCH 08/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 0162475..149f7fa 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -66,17 +66,17 @@ There is also work that can be done to make the test suite more robust such as: ## Implementations Current SHACL-C implementations include those listed below. -Parsers/writers (i.e. convertors between SHACL and SHACL-C) - - TopQuadrant had a SHACL-C implementation that is deprecated in favor of Jena's. +**Parsers/writers** (i.e., convertors between SHACL and SHACL-C) + - TopQuadrant had a SHACL-C implementation that was deprecated in favor of Jena's. The the current SHACL-C specification [cites the grammar](https://w3c.github.io/shacl/shacl-compact-syntax/#grammar-section) of this implementation - [Jena](https://jena.apache.org/documentation/shacl/#shacl-compact-syntax): implemented in Java - [allotrope-open-source/shape-editor](https://gitlab.com/allotrope-open-source/shape-editor): implemented in Java for the Eclipse framework (uses XTEXT). - Introduces a number of number of new SHACL-C Constructs (see https://github.com/w3c/shacl/issues/52 ), reflected above + Introduces a number of number of new SHACL-C Constructs (see https://github.com/w3c/shacl/issues/52), reflected above. - [jeswr/shaclcjs](https://github.com/jeswr/shaclcjs) and [jeswr/shaclc-writer](https://github.com/jeswr/shaclc-writer): implemented in JavaScript - [edmondchuc/shaclc](https://github.com/edmondchuc/shaclc): implemented in Python, also has a [playground](https://edmondchuc.github.io/shaclc/) -Editing helpers: -- [jeswr/shaclc-language-server](https://github.com/jeswr/shaclc-language-server): Language Server, implements intellisense features for modern IDEs like VS-Code +**Editing helpers** +- [jeswr/shaclc-language-server](https://github.com/jeswr/shaclc-language-server): Language Server, implements IntelliSense-like features for modern IDEs like VS-Code - [VladimirAlexiev/shaclc-mode](https://github.com/VladimirAlexiev/shaclc-mode): for Emacs, implements syntax checking and highlighting, jumping from reference to definition From b8ff05a40bd539ed97771dcefd91b9c4dbdc6505 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:15:20 +0300 Subject: [PATCH 09/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 149f7fa..59e68a3 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -41,10 +41,10 @@ A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-sourc - [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape), but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, and have `IF` (being a shape to check) and `PRIORITY` parts - [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation -- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. you don't need to do `""""""`. - 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. +- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e., you don't need to do `""""""`. + - 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. - [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (e.g., `><`, `⊻`, and/or `⩒`) in addition to keywords (e.g., `xone` and/or `xor`). This is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable, and we expect that, like all models, they are far more often read then written, but where the boundary of obscurity ends is open to discussion. From 416c5355e1312fc37366405e6666635f9838a801 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:15:43 +0300 Subject: [PATCH 10/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 59e68a3..d718321 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -33,10 +33,10 @@ A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-sourc For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) - Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. - 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. + The inclusion of SPARQL resulted from implementation experience that expressiveness of SHACL alone was not enough for the Allotrope use case. + For example, we need to ensure the unique presence of some nodes in an Allotrope file, and use the SHACL SPARQL extension for it. + If we support SPARQL at all, it feels natural to also apply it to `SELECT` targets. + Allotrope uses SPARQL sparingly because it is "only" a SHACL extension, so from the view of many of the Allotrope members, not "official" enough. - [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) - [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape), but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, and have `IF` (being a shape to check) and `PRIORITY` parts - [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions From ec49e88b7da503258c41a0e1cbbd5229760068f3 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Sun, 11 Aug 2024 11:49:38 +0300 Subject: [PATCH 11/15] move speculative features into subsection ### Extra SHACL Features --- shacl-compact-syntax/scope.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index d718321..9a7ecfd 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -18,14 +18,26 @@ Note that this should be done *after* these features have been supported by the ## New Features -### Support for Additional SHACL-C Constructs -- shorthand (`<`, `=`, `<=`, etc.) for property pair constraints +### Extra SHACL-C Syntax Features + +The following features will allow SHACL-C to capture more of SHACL, or express it in a nicer way: + +- Shorthand (`<`, `=`, `<=`, etc.) for property pair constraints - [Support `xone` and more `or` cases](https://github.com/w3c/shacl/issues/12) - Opt out of the production of the triple `?baseUri rdf:type owl:Ontology` - Non-validating characteristics (e.g., generating `sh:order` triples by declaring `@order` at the top of a file/shape, allow grouping by `@group` at the top of a set of properties, and allowing a `@description` above properties). -- Target shapes, see [rsx:targetShape](https://rdf4j.org/shacl/extensions.html) +- [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (e.g., `><`, `⊻`, and/or `⩒`) in addition to keywords (e.g., `xone` and/or `xor`). + This is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable, and we expect that, like all models, they are far more often read then written, but where the boundary of obscurity ends is open to discussion. + +### Extra SHACL Features -A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext) by [Allotrope](https://www.allotrope.org/): +The following features would extend SHACL, so are subject of discussion. +The first one comes from RDF4J. +The rest come from [SPARQL Inferencing Notation (SPIN)](https://spinrdf.org/) (the predecessor of SHACL) +and/or the [Allotrope](https://www.allotrope.org/) Shapes Editor (see [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext)). +Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. + +- Target shapes, see [rsx:targetShape](https://rdf4j.org/shacl/extensions.html) (implemented in RDF4J ShaclSail) - [Shape Libraries](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ShaclDoc) (versioned). Packaging shapes into libraries enables modularized development of shapes. It is used together with [Import](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl). A shape library is very similar to an OWL ontology and technically works in the same way. @@ -45,10 +57,6 @@ A number of features from [SHACLC.xtext](https://gitlab.com/allotrope-open-sourc - 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. -- [Graphical Operators](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#OP_XONE) (e.g., `><`, `⊻`, and/or `⩒`) in addition to keywords (e.g., `xone` and/or `xor`). - This is a way to make SHACL-C even more compact, but many people cannot type them easily. The use of well-known operators can help make code more readable, and we expect that, like all models, they are far more often read then written, but where the boundary of obscurity ends is open to discussion. - -Some or all of these additions may be ignored in favour of keeping SHACL-C a simple syntax to implement and use. ### [Making SHACL-C Lossless](https://github.com/w3c/shacl/issues/36) From 8ed7cef6c2b8787e9b694e08763b6ab4bd1ece1c Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Mon, 12 Aug 2024 07:57:06 +0300 Subject: [PATCH 12/15] move some features back into ### Extra SHACL-C Syntax Features, referencing SHACL Advanced --- shacl-compact-syntax/scope.md | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 9a7ecfd..4334699 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -22,7 +22,13 @@ Note that this should be done *after* these features have been supported by the The following features will allow SHACL-C to capture more of SHACL, or express it in a nicer way: +- [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions, [part of SHACL Advanced](https://w3c.github.io/data-shapes/shacl-af/#functions) - Shorthand (`<`, `=`, `<=`, etc.) for property pair constraints +- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape). + - [These rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, like SHACL Advanced [SPARQL Rules](https://w3c.github.io/data-shapes/shacl-af/#SPARQLRule) `sh:construct` + - Note: SHACL Advanced also has [Triple Rules](https://w3c.github.io/data-shapes/shacl-af/#TripleRule) (`subject, property, object`), and we need a syntax for that + - They have `IF` part being a shape to check, like [sh:condition](https://w3c.github.io/data-shapes/shacl-af/#condition) + - They have `PRIORITY` part, like [sh:order](https://w3c.github.io/data-shapes/shacl-af/#rules-order) - [Support `xone` and more `or` cases](https://github.com/w3c/shacl/issues/12) - Opt out of the production of the triple `?baseUri rdf:type owl:Ontology` - Non-validating characteristics (e.g., generating `sh:order` triples by declaring `@order` at the top of a file/shape, allow grouping by `@group` at the top of a set of properties, and allowing a `@description` above properties). @@ -43,20 +49,25 @@ Some or all of these additions may be ignored in favour of keeping SHACL-C a sim A shape library is very similar to an OWL ontology and technically works in the same way. In fact, we now use OWL ontologies because of inference from `owl:import`, but there was quite some discussion about whether the assembly of shapes is an ontology in the OWL sense. For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. -- [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) +- [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) (how is this different from `owl:imports`?) - Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. The inclusion of SPARQL resulted from implementation experience that expressiveness of SHACL alone was not enough for the Allotrope use case. For example, we need to ensure the unique presence of some nodes in an Allotrope file, and use the SHACL SPARQL extension for it. If we support SPARQL at all, it feels natural to also apply it to `SELECT` targets. Allotrope uses SPARQL sparingly because it is "only" a SHACL extension, so from the view of many of the Allotrope members, not "official" enough. - [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) -- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape), but unlike SHACL-AF rules that have `subject, property, object` or SPARQL, [these rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, and have `IF` (being a shape to check) and `PRIORITY` parts -- [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation -- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e., you don't need to do `""""""`. - - 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. +- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. unlike SHACL SPARQL, SPARQL is not embedded in RDF literals (`""""""`) . + - Potential benefits: + - 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. + - Using a more explicit SPARQL representation (not embedded in RDF literals) gives a better chance of implementing uncremental evaluation. + - Potential disadvantages: + - Copies large parts of the SPARQL grammar. + - To be compatible with SHACL, we need to devise a target RDF representation for this dedicated syntax. + There was [SPIN SPARQL Syntax](https://spinrdf.org/sp.html) (RDF triple constructs for expressing SPARQL queries), which SHACL abandoned because it was too wordy. + - Need to devise two algorithms: "SHACL parsing and compilation to triples" and "generation of SHACL from triples" ### [Making SHACL-C Lossless](https://github.com/w3c/shacl/issues/36) From f2eaf813b31e70f3eb9447ee0cd539c613595581 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Mon, 12 Aug 2024 08:14:38 +0300 Subject: [PATCH 13/15] move one more to ### Extra SHACL-C Syntax Features, add link https://github.com/w3c/shacl/issues/74 --- shacl-compact-syntax/scope.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 4334699..6bbfae7 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -22,13 +22,19 @@ Note that this should be done *after* these features have been supported by the The following features will allow SHACL-C to capture more of SHACL, or express it in a nicer way: -- [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions, [part of SHACL Advanced](https://w3c.github.io/data-shapes/shacl-af/#functions) +- [SPARQL Functions](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#FunctionShape), inspired by SPIN Functions, like SHACL Advanced [functions](https://w3c.github.io/data-shapes/shacl-af/#functions) - Shorthand (`<`, `=`, `<=`, etc.) for property pair constraints -- [Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape). +- [SPARQL Rules](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleShape). - [These rules use](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#RuleBody) `CONSTRUCT`, like SHACL Advanced [SPARQL Rules](https://w3c.github.io/data-shapes/shacl-af/#SPARQLRule) `sh:construct` - Note: SHACL Advanced also has [Triple Rules](https://w3c.github.io/data-shapes/shacl-af/#TripleRule) (`subject, property, object`), and we need a syntax for that - They have `IF` part being a shape to check, like [sh:condition](https://w3c.github.io/data-shapes/shacl-af/#condition) - They have `PRIORITY` part, like [sh:order](https://w3c.github.io/data-shapes/shacl-af/#rules-order) +- Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. + The inclusion of SPARQL resulted from implementation experience that expressiveness of SHACL alone was not enough for the Allotrope use case. + For example, we need to ensure the unique presence of some nodes in an Allotrope file, and use the SHACL SPARQL extension for it. + If we support SPARQL at all, it feels natural to also apply it to `SELECT` targets. + Allotrope uses SPARQL sparingly because it is "only" a SHACL extension, so from the view of many of the Allotrope members, not "official" enough. +- [Parameterized SPARQL Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) and [their invocation](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetCall), like SHACL Advanced [SPARQL Target Types](https://w3c.github.io/data-shapes/shacl-af/#SPARQLTargetType) - [Support `xone` and more `or` cases](https://github.com/w3c/shacl/issues/12) - Opt out of the production of the triple `?baseUri rdf:type owl:Ontology` - Non-validating characteristics (e.g., generating `sh:order` triples by declaring `@order` at the top of a file/shape, allow grouping by `@group` at the top of a set of properties, and allowing a `@description` above properties). @@ -37,7 +43,8 @@ The following features will allow SHACL-C to capture more of SHACL, or express i ### Extra SHACL Features -The following features would extend SHACL, so are subject of discussion. +The following features would extend SHACL, so are subject of discussion (https://github.com/w3c/shacl/issues/74). + The first one comes from RDF4J. The rest come from [SPARQL Inferencing Notation (SPIN)](https://spinrdf.org/) (the predecessor of SHACL) and/or the [Allotrope](https://www.allotrope.org/) Shapes Editor (see [SHACLC.xtext](https://gitlab.com/allotrope-open-source/shape-editor/-/blob/master/src/com.osthus.shapes.shaclc.parent/com.osthus.shapes.shaclc/src/com/osthus/shapes/shaclc/SHACLC.xtext)). @@ -50,12 +57,6 @@ Some or all of these additions may be ignored in favour of keeping SHACL-C a sim In fact, we now use OWL ontologies because of inference from `owl:import`, but there was quite some discussion about whether the assembly of shapes is an ontology in the OWL sense. For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) (how is this different from `owl:imports`?) -- Rich [Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#Target) including SPARQL targets. - The inclusion of SPARQL resulted from implementation experience that expressiveness of SHACL alone was not enough for the Allotrope use case. - For example, we need to ensure the unique presence of some nodes in an Allotrope file, and use the SHACL SPARQL extension for it. - If we support SPARQL at all, it feels natural to also apply it to `SELECT` targets. - Allotrope uses SPARQL sparingly because it is "only" a SHACL extension, so from the view of many of the Allotrope members, not "official" enough. -- [Parameterized Targets](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#TargetShape) - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation - [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. unlike SHACL SPARQL, SPARQL is not embedded in RDF literals (`""""""`) . - Potential benefits: From ea03ebc6e65993732dbf224f32e38e7ecd35cee9 Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Mon, 12 Aug 2024 08:42:06 +0300 Subject: [PATCH 14/15] reference https://github.com/w3c/shacl/issues/75 --- shacl-compact-syntax/scope.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 6bbfae7..52258fb 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -58,17 +58,12 @@ Some or all of these additions may be ignored in favour of keeping SHACL-C a sim For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) (how is this different from `owl:imports`?) - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation -- [Dedicated Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. unlike SHACL SPARQL, SPARQL is not embedded in RDF literals (`""""""`) . +- [Explicit Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. SPARQL is not embedded in RDF literals (`""""""`), unlike SHACL SPARQL. - Potential benefits: - 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. - - Using a more explicit SPARQL representation (not embedded in RDF literals) gives a better chance of implementing uncremental evaluation. - - Potential disadvantages: - - Copies large parts of the SPARQL grammar. - - To be compatible with SHACL, we need to devise a target RDF representation for this dedicated syntax. - There was [SPIN SPARQL Syntax](https://spinrdf.org/sp.html) (RDF triple constructs for expressing SPARQL queries), which SHACL abandoned because it was too wordy. - - Need to devise two algorithms: "SHACL parsing and compilation to triples" and "generation of SHACL from triples" + - Issue https://github.com/w3c/shacl/issues/75 discusses whether to reintroduce an explicit RDF syntax for SPARQL. ### [Making SHACL-C Lossless](https://github.com/w3c/shacl/issues/36) From 30ac7e364c24dd3ec6eb886dddab5eaf14b5d5df Mon Sep 17 00:00:00 2001 From: Vladimir Alexiev Date: Fri, 23 Aug 2024 10:00:03 +0300 Subject: [PATCH 15/15] accept @TallTed suggestions Co-authored-by: Ted Thibodeau Jr --- shacl-compact-syntax/scope.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shacl-compact-syntax/scope.md b/shacl-compact-syntax/scope.md index 52258fb..076fa05 100644 --- a/shacl-compact-syntax/scope.md +++ b/shacl-compact-syntax/scope.md @@ -58,7 +58,7 @@ Some or all of these additions may be ignored in favour of keeping SHACL-C a sim For any large scale application of SHACL, it is necessary to modularize, and it felt like this was a serious gap in the specification. - [Imports](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ImportsDecl) (how is this different from `owl:imports`?) - Rich [Parameter Declarations](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#ParameterDeclaration) and respective assignments at invocation -- [Explicit Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e. SPARQL is not embedded in RDF literals (`""""""`), unlike SHACL SPARQL. +- [Explicit Syntax](https://rawgit2.com/VladimirAlexiev/shacl/shaclc-grammars/shacl-compact-syntax/grammar/shaclc-XText.html#SparqlConstraint) for SPARQL Constraints, i.e., SPARQL is not embedded in RDF literals (`""""""`), unlike SHACL SPARQL. - Potential benefits: - Having a syntax for SPARQL allows a much better integration. - We do not have a language within a language.