You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: