Don't use parasitic `PropertyShape`

[VladimirAlexiev]

The shape shown in https://github.com/Sveino/Inst4CIM-KG/issues/17 (and many like it) is structured like this:

erc:EnergyComponent  a          sh:NodeShape ;
        sh:property      erc:EnergyComponent-associations;
        sh:targetClass  nc:EnergyComponent .

erc:EnergyComponent-associations
        a               sh:PropertyShape ;
        sh:description  "The EnergyComponent shall be associated with either GeneratingUnit, PowerElecronicsUnit, EnergyConsumer or HydroPump." ;
        sh:sparql       erc:EnergyComponent-associationsSparql ;
        sh:path         rdf:type ;
        sh:group        erc:ERgroup ;
        sh:name         "C:NC:ER:EnergyComponent:associations" ;
        sh:order        2 ;
        sh:severity     sh:Violation .

erc:EnergyComponent-associationsSparql a         sh:SPARQLConstraint ;  
  ...

The PropertyShape is parasitic:

• the constraint checks for the presence of one of 4 props, and rdf:type has nothing to do with them
• sh:sparql is invoked not on the original target node, but on its type node! Which (given sh:targetClass) is always nc:EnergyComponent: of course that node has none of the 4 desired outgoing props

So it should be changed to:

erc:EnergyComponent-associations  a          sh:NodeShape ;
        sh:targetClass  nc:EnergyComponent .
        sh:message "The EnergyComponent shall be associated with either GeneratingUnit, PowerElecronicsUnit, EnergyConsumer or HydroPump." ;
        sh:sparql       erc:EnergyComponent-associationsSparql ;
        sh:name         "C:NC:ER:EnergyComponent:associations" ;
        sh:severity     sh:Violation .

erc:EnergyComponent-associationsSparql a         sh:SPARQLConstraint ;  
  ...

According to https://w3c.github.io/data-shapes/shacl/#constraints-section: sh:name, sh:description, sh:order, sh:group apply only to sh:PropertyShape.

• I've moved description to sh:message
• I left sh:name but looking at the value, maybe it's better to use eg skos:notation, which is intended for such sort of specialized "identifiers"

[griddigit-ci]

Here we will need to check all design patterns and describe them. We will also need to see if we change the style depending on the usage and see how this impacts the validation report.

the sh:message was put in sparql part to be able to print variable there using {?x} as part of the message. i am not sure if this would work if the message is in the NodeShape

The pattern to use (at least in most cases) NodeShape, explicit PropertyShape and the SPARQL was to be able to refer to this PropertyShape from multiple nodes and it also brings some more clarity in the validation report. In general W3C is using a lot of blank nodes for the sh:property which was not coming handy in many places

the path rdf:type is an artificial thing as some python validators complained that property shape is missing sh:path. Jena was not having issues with missing sh:path. In that particular case we do not needed as it is not used in the sparql part We need to see how to deal with these nuances and test the patterns in multiple validation engines

[VladimirAlexiev]

• You should write your shapes by first conforming to the SHACL spec, and only secondarily catering to the peculiarities of specific SHACL engines
• path is mandatory for PropertyShape: https://www.w3.org/TR/shacl/#property-shapes. In fact the spec defines PropertyShape by the presence of path (i.e. the type PropertyShape is optional).
• "the sh:message was put in sparql part to be able to print variable there using {?x} as part of the message: yes, but this one doesn't have variables. Nevertheless, https://www.w3.org/TR/shacl/#x5.3.2-mapping-of-solution-bindings-to-result-properties says that it looks for sh:message in the SPARQL part so you've placed it correctly.
• "to be able to refer to this PropertyShape from multiple nodes and it also brings some more clarity in the validation report":
  • If you need to check those 3 props comprehensively, then use sh:or in NodeShape. Then you can reuse the PropertyShapes of the individual props.
  • If you only need to check the presence of those 3 props, then use sh:alternatePath in PropertyShape. Then you can reuse that PropertyShape
  • If you want to reuse SPARQL constraints, then use https://www.w3.org/TR/shacl/#sparql-constraint-components
• "need to check all design patterns and describe them": agree! This will be a major part of my engagement, but I haven't come yet to it. I cannot check thousands of shapes comprehensively, but I can check the 20-100 patterns that they are generated from. We should cover this fully on Sep 24: cc @Sveino
• "and test the patterns in multiple validation engines": agree! This will be a major part of my engagement
• "depending on the usage and see how this impacts the validation report": agree! Unfortunately SHACL doesn't specify all details here, so getting useful validation reports out of validation engines is a challenge.

[VladimirAlexiev]

We should consider creating new https://www.w3.org/TR/shacl/#sparql-constraint-components because if they are used often, then validator vendor may decide to implement them specially, thus optimizing performance.

[griddigit-ci]

I guess this requires to package the issues and have dedicated SHACL discussion