I am struggling to understand (for me) a very unintuitive feature regarding the inheritance of shape constraints. My problem is that when i try to inherit shape constraints via rdfs:subClassOf, this works only when the inheritance is specified in the data graph, not when it is specified in the shapes graph.
I have validated the following PoC in both the old and Zazuko SHACL playgrounds and receive identical answers.
The shapes graph:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Agent a rdfs:Class,
sh:Nodeshape;
sh:property [
sh:minCount 1;
sh:path :Name;
].
:Adult rdfs:subClassOf :Agent.
The Data graph:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Father a :Adult.
:UnknownPerson a :Agent.
This version only demands that :UnknownPerson should have at least one :Name property, but when I move the :Adult rdfs:subClassOf :Agent to the data graph, it immediately recognizes that both :Father and :UnknownPerson should have it.
I do not understand why I cannot define this inheritance in the shapes graph itself?
If on a more fundamental RDFs level :Adult class is defined as the subclass (subset) of the :Agent class and as such it should also be a sh:NodeShape, why aren't the property constraints applied to it when it is defined as part of the schema and not as part of the data to be validated?
This is a very valid question and the decision could have gone either way. The working group that defined SHACL ended up with the current design - requiring rdfs:subClassOf triples in the data graph for the target mechanism and in places like sh:class - because it was deemed to be more consistent and self-contained. The basic concept is "SHACL instance" which determines whether a node counts as an instance of a class. Given that the rdf:type triple will, of course, be in the data graph, we thought it best to also assume that the subClassOf triples be in the same graph.
Among others, this means that algorithms don't need to switch between graphs (e.g. in SPARQL it would be the path expression rdf:type/rdfs:subClassOf*), and that shapes graphs can be compiled into some static data structure that makes sure that the original RDF shapes graph doesn't need to be queried again during validation. There may have been other reasons for the current design that I have forgotten. As usual, the archive of the meeting minutes of the W3C Data Shapes WG may have more details.
In practice, the issue is often worked around by including the shapes graph into the data graph, e.g. using owl:imports. This way, the rdfs:subClassOf triples only need to be asserted in the shapes graph yet are also visible in the data graph.