Re: Choice between patterns

I tend to use the first pattern in order to inherit property constraints. 

With this approach I may have a class Person and a class Employee which is a subclass of Employee. I associate property constraints with them directly. So, I may say, for example,  that a person must have a first name and a last name, they must be strings, there must be a single last name and they must have a gender which comes from a pre-defined list and there must be one gender, etc. Then, I do not have to repeat these constraints for the Employee. Instead, I would only add constraints that are specific for Employees - may be the fact that there is Employee ID or the fact that Employee must be older than 16 or whatever rules exist for employees.

The constraints do not have to be in the same graph with the subclass statements, they could be in a separate graph that imports the graph(s) containing class declarations (e.g., ex:Person a rdfs:Class. ex:Person rdfs:label Person), subclass statements and property declarations. If your targets are members of a certain class, I do not see any downsides of this approach. If you need to have different shapes for different applications/requirements, you can have different shape graphs importing the same graph(s) that define classes and properties. This will let you create different shapes for the same classes.

If one keeps PersonShape and EmployeeShape as separate resources from Person and Employee classes, they would use ‘sh:and’ to re-use property constraints. They would define PersonShape, then create EmployeeShape and define it as PersonShape plus (sh:and) constraints that are specific to employees. This is a more verbose approach that requires one to have extra resources, extra target triples plus use sh:and in the shape definitions.

I would recommend using the second pattern when you (as the shape developer) expect that there is no single class that would identify all resources that must comply to the shape. 

For example, you may want to use a given shape to validate resources that belong to different classes that do not have a common superclass and you think that using the shape class as a common superclass would not be feasible. In other words, you have ex1:Person and ex2:Person and you don’t thin it may be possible or desirable to add {ex1:Person rdfs:subClassOf ex:Person, ex2:Person rdfs:subClassOf ex:Person} where ex:Person is your shape class. You can then address this situation by creating two different sh:targetClass statements for each of the classes. This may happen if there are different people/communities who have created different classes independently from each other, they don’t want to use the sub class relationship even if it is stated in a separate graph just to enable validation, yet they want to use the same shape to validate their data. In my experience such cases don’t happen often because a shape defines constraints for some properties. So, for this situation to happen, data would use the same properties, but different classes. 

Another situation that requires this approach is when data has no type statements or the type statements do not identify resources you want to validate against the shape. To address this situation you can use target statements that are not class based. 

> On Jun 17, 2017, at 2:00 PM, Peter Bruhn Andersen <bruhn.andersen@webspeed.dk> wrote:
> 
> As I understand it we can use (at least) two patterns to define a shape for a class. Using the examples in the specification we can declare a shape for the class ex:Person either by directly declaring ex:Person as type sh:NodeShape
> 
> ex:Person
> 
>    a rdfs:Class, sh:NodeShape .
> 
>  or we can declare a nodeshape class that use sh:targetClass with ex:Person as object
> 
> ex:PersonShape
> 
>    a sh:NodeShape ;
> 
>    sh:targetClass ex:Person ;
> 
> What would be the implication of each of these two patterns?
> 
> Are there any pro and cons to the two?
> 
> In which situations should I choose the first instead of the latter?
> 
>  
> Regards,
> 
> Peter
> 
>