SHACL: how to use sh:class with a superclass?

[VladimirAlexiev]

https://github.com/Sveino/Inst4CIM-KG/tree/develop/shacl-improved#properties-target-sibling-ranges

@griddigit-ci

usage of sh:class instead of sh:in for cases when we have more reference to a single class. This is the current way we do things after the recommendation we got. It is applied to NC profiles, but now this causes a few issues as sh:class also checks the existence of the reference. We need to be able to validate single files. With the setup we currently have we need to do some configuration tricks to disable some shapes that we know would give false alarm when validating single file and activate them when validating multiple files, etc.

Can you please elaborate?

• duplicate type statements across named graphs Sveino/Inst4CIM-KG#164: is this issue related?

I know CIM says that if a node defined in profile X is referenced in profile Y, then it must have rdf:type in Y.
But subclass inference is the same across profiles: so the node will get the same ancestor classes in both X and Y.

So what exactly is the problem?

[griddigit-ci]

In the original setup we used the following construct to check for the correct rdf:type when following the reference
sh:in (cim:Terminal);
sh:path (cim:MutualCoupling.First_Terminal rdf:type) ;

and similar construct when we have a real list in sh:in like this example

    sh:in           (cim:NonConformLoad cim:Jumper cim:EquivalentShunt cim:Fuse cim:Cut cim:Junction cim:PowerElectronicsConnection cim:CsConverter cim:EnergyConsumer cim:AsynchronousMachine cim:SynchronousMachine cim:EquivalentBranch cim:Clamp cim:DisconnectingCircuitBreaker cim:EquivalentInjection cim:StationSupply cim:BusbarSection cim:ACLineSegment cim:StaticVarCompensator cim:Disconnector cim:GroundingImpedance cim:LoadBreakSwitch cim:PowerTransformer cim:PetersenCoil cim:Switch cim:LinearShuntCompensator cim:Ground cim:SeriesCompensator cim:GroundDisconnector cim:VsConverter cim:Breaker cim:EnergySource cim:NonlinearShuntCompensator cim:ExternalNetworkInjection cim:ConformLoad cim:Equipment);

sh:path (cim:SvStatus.ConductingEquipment rdf:type ) ;

Based on previous discussions what we manage to implement is the change on case 1, i.e. when we point to 1 class now we use this

sh:class cim:Terminal;
sh:path cim:MutualCoupling.First_Terminal;

The fix of the 2nd part when we have more than one class can be implemented when we sort out the issue that prevents us to point to abstract class or just to a class in upper hierarchy

In the ideal word we will have 3 cases

• use sh:class when we refer, need to check the type of single class
• use sh:class when we refer, need to check the type of all classes in a hierarchical chain, but this will work if sh;class supports the subclasses, which I guess it should, but to be tested
• use the sh:in when we have combination and we need to go explicit as we also checked, I think, that we cannot do sh:class and have multiple

So far so good, we have 2 todo-s here

• apply pattern 1 for CGMES v3 profiles as there it was not done, NC is using sh:class
• figure out the usage of inheritance tree by SHACL engines

The headache with the sh:class is that it reports dangling reference too, which was not the case when using sh:path (cim:MutualCoupling.First_Terminal rdf:type)
This is understandable and according to definitions, but it also requires to see how do we split the constraints when we validate single datasets when we know there is dangling reference and we want to get rid of the false reporting. there are multiple ways how to go around this, but we need to see what the best practice will be.

[VladimirAlexiev]

1. Because of the strict UML model, i think that "pick some subclasses but not all" is invalid. Eg SvStatus.ConductingEquipment admits any ConductingEquipment, right?

2. When is a dangling reference ok? I think that never. Eg when you validate SSH that depends on an EQ:

• it should rely that the EQ is loaded, so it can check the existence of the referenced equipment
• or should at least include redundant type statements. I think the CIM standard requires that, but these duplicate statements may create problems in some situations

[griddigit-ci]

Because of the strict UML model, i think that "pick some subclasses but not all" is invalid. Eg SvStatus.ConductingEquipment admits any ConductingEquipment, right?
=> this is rare situation if it exist. I think we hit it, but now I cannot recall it. So we need to watch.

When is a dangling reference ok? I think that never. Eg when you validate SSH that depends on an EQ:

it should rely that the EQ is loaded, so it can check the existence of the referenced equipment
or should at least include redundant type statements. I think the CIM standard requires that, but these duplicate statements may create problems in some situations

=>the statements duplication there happens only if the association goes from EQ to TP for example for associations going from SV to TP or other cases like this is just rdf:resource reference. if the validation happens on the condition that we have all datasets available we would not have that problem, but there is a requirement to validate separate datasets too and here we have the issue.