Add semantic information to shape trees to discriminate between different resource classes

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:

<#TaskTree>
  a st:ShapeTree ;
  st:expectsType st:Resource ;
  st:shape pm-shex:TaskShape ;
  st:targetClass pm:Task .

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.

Start with the Shape Trees specification's validateResource algorithm, the shape tree namespace, and the linked specification issue and hierarchy example. Determine how targetClass should be defined and used to distinguish resource classes; done means the specification consistently describes that behavior and the Task/Project examples no longer validate interchangeably.