A couple of months ago I bumped into what I think is a malfunction of the validateResource algorithm of the shape tree specification that I described in this issue. Basically, trying to implement a shape tree validator that would execute the algorithm on the resources of the hierarchy described in an example found in the interoperability specification, I discovered that a "Task" resource is validated with a true result against a "Project" shape tree (and viceversa). This is due to the fact that the shape validation would check for constraints on the Project shape and wouldn't find any constraint for the task resource. I think this should not be an intended behavior and users should have the possibility to discriminate between different shape trees when validating a certain resource.
My solution is to add to the shape tree namespace a property similar to this one:
:targetClass
a owl:ObjectProperty ;
rdfs:domain :ShapeTree ;
rdfs:range rdfs:Class ;
rdfs:comment "Specifies the class of the managed resource"@en ;
rdfs:isDefinedBy <> ;
rdfs:label "targetClass"@en .
And so for example the TaskShapeTree could look like this:
And the validateResource algorithm could check if the shape tree has a st:targetClass property and, in that case, if the targetClass is the same of the class of the resource.
A couple of months ago I bumped into what I think is a malfunction of the validateResource algorithm of the shape tree specification that I described in this issue. Basically, trying to implement a shape tree validator that would execute the algorithm on the resources of the hierarchy described in an example found in the interoperability specification, I discovered that a "Task" resource is validated with a true result against a "Project" shape tree (and viceversa). This is due to the fact that the shape validation would check for constraints on the Project shape and wouldn't find any constraint for the task resource. I think this should not be an intended behavior and users should have the possibility to discriminate between different shape trees when validating a certain resource.
My solution is to add to the shape tree namespace a property similar to this one:
And so for example the TaskShapeTree could look like this:
And the validateResource algorithm could check if the shape tree has a st:targetClass property and, in that case, if the targetClass is the same of the class of the resource.