Clarify the domain of the logical constraint components
Closed this issue · 2 comments
What is the intended domain of the location constraint components?
The vocabulary does not include rdfs:domain
statements for these properties. I'm assuming these components all have the same domain, although this is not stated explicitly in the standard.
I find a little bit of evidence for the following two variants.
Variant 1: The domain is sh:Shape
Section 4.6 states that these components can be applied to shapes (i.e. both nodes shapes and property shapes). For example the following sentence:
sh:not
specifies the condition that each value node cannot conform to a given shape.
Some of the SHACL implementation libraries seem to follow this reading. They allow the following shape to be used (notice that sh:or
appears on a property shape):
shp:A
sh:property shp:A_p;
sh:targetClass def:A.
shp:A_p
sh:or
( [ sh:class def:B ]
[ sh:class def:C ] );
sh:path def:p.
Variant 2: The domain is sh:NodeShape
The image at the beginning of Section 2 indicates that one of the location constraint components (sh:or
) appears on nodes shapes.
This means that the above snippet should have been written as follows:
shp:A
sh:or
( [ sh:property
[ sh:class def:B;
sh:path def:p ] ]
[ sh:property
[ sh:class def:C;
sh:path def:p ] ] );
sh:targetClass def:A.
Notice that this notation is more complex than the one under variant 1 and repeats more elements.
sh:not, sh:or and sh:and can be applied to both property shapes and node shapes. The definitions of these constraint components all use generic SHACL terminology such as "value node" and "focus node", where value node has a different meaning depending on whether you are in a property shape or a node shape.
SHACL does not rely on RDFS so we may have used rdfs:domain in some places but not others, for illustration purposes and to help RDFS-aware tools. I guess in this case it could have been rdfs:domain sh:Shape.
Thanks @HolgerKnublauch , I now see that I can close this issue based on your feedback.