BenediktHeinrichs
commented
3 years ago I created a minimal code example for this issue, which can test this problem:
Closed BenediktHeinrichs closed 3 years ago
BenediktHeinrichs
commented
3 years ago I created a minimal code example for this issue, which can test this problem:
BenediktHeinrichs
commented
3 years ago It seems to be linked to the function defined here: https://github.com/zazuko/rdf-validate-shacl/blob/master/src/rdflib-graph.js#L19
It finds in the example SoftwareShape for ToolShape but not AnalysisSoftwareShape.
martinmaillard
commented
3 years ago Hey there, Thanks for the report.
I'm not really sure if inheritance between shapes is defined by SHACL. Do you know anything about that @bergos @tpluscode ?
HolgerKnublauch
commented
3 years ago The example uses Implicit Class Targets, see https://www.w3.org/TR/shacl/#implicit-targetClass - the instance of AnalysisSoftwareShape will be validated against the AnalysisSoftwareShape class as shape. The rather cryptic terms "SHACL shape" and "SHACL instance" mean that rdfs:subClassOf triples must be walked up implicitly. Consider any instance of AnalysisSoftwareShape also an instance of SoftwareShape, and recursively of ToolShape. Given that any instance of a subclass is also an instance of the superclass(es), they are also targeted by the SHACL definitions of those superclasses.
So yes, it needs to walk up to the root class and apply all constraints.
BTW: the sh:targetClass statements in the example are unnecessary. The usual design pattern for that would be to have
ex:ToolShape
a sh:NodeShape ;
sh:targetClass ex:Tool .
ex:Tool
a rdfs:Class .
ex:MyTool
a ex:Tool .in which case the ToolShape will apply to MyTool. The other main pattern is
ex:Tool
a rdfs:Class, sh:NodeShape .
ex:MyTool
a ex:Tool .assuming all constraints are directly attached to ex:Tool.
martinmaillard
commented
3 years ago Thanks Holger, that's very helpful. I didn't know about the "Implicit Class Targets" feature, which opens up a lot of possibilities :)
martinmaillard
commented
3 years ago Fixed in #42
Recently, I have been trying to create shapes which inherit properties from other shapes.
Using this library, the validation went fairly well until I hit the second inherited level.
This means that having a construct of Shape C > Shape B and Shape B > Shape A, the properties of Shape B will be validated, the properties of Shape A however won't.
I tried this construct in the https://shacl.org/playground/ and this supports the structure, so I assume there is something not working correctly.
In the following I provide an example shape graph and data graph which validates correctly that the field "schema:name" is missing in the playground, however does not report that issue using this library.
Shapes Graph:
``` @prefix dash:Data Graph:
``` [ { "@type":"http://schema.org/AnalysisSoftwareShape", "http://schema.org/version":{ "@value":"ü+", "@type":"http://www.w3.org/2001/XMLSchema#string" }, "http://schema.org/creator":{ "@value":"pop", "@type":"http://www.w3.org/2001/XMLSchema#string" } }, { "@id":"http://schema.org/SoftwareShape", "http://www.w3.org/2000/01/rdf-schema#subClassOf":[ { "@id":"http://schema.org/ToolShape" } ] }, { "@id":"http://schema.org/AnalysisSoftwareShape", "http://www.w3.org/2000/01/rdf-schema#subClassOf":[ { "@id":"http://schema.org/SoftwareShape" } ] }, { "@id":"http://schema.org/ToolShape" } ] ```