some comments on SHACL editors' draft of 8 November

Comments on editors' draft of 8 November

There are still serious problems with the description of the basic
terminology and operation of SHACL.  Among other problems, it is unclear
what a constraint or constraint component is, how constraints are validated,
how targets are determined, when targets are used, and how focus nodes are
determined.  There needs to be a complete and thorough examination of the
document by the working group to check for problems in the definition of the
basic notions underlying SHACL.


Here are some specific problems that I noticed in a quick read of the first
two sections of the document.

"A constraint component is an IRI in the shapes graph."  However, most of
the IRIs that are constraint components do not show up in shapes graphs.

"A constraint is a node in the shapes graph".  The first example, in Section
1.4, talks about four constraints.  Three of these are obvious nodes in example
shapes graph, but the node for the fourth is unclear.

"The validation report is the result of the validation process".  Section
1.4 states that a particular graph *is* the result of validation, indicating
that no additional information can be included in the validation report.
How then can properties, like sh:name, that seem to have optional status be
useful?

"Targets MUST be ignored when a shape is processed as a value of parameters
of shape-based constraint components (i.e. sh:shape), logical constraint
components (i.e. sh:or), or filter shapes (sh:filterShape)."  This notion of
processing is not defined in the document.

"A node target is defined with the sh:targetNode predicate. Each value of
sh:targetNode can be an IRI or a literal. Each value of a node target
defines a node to validate in the data graph."   This doesn't say how a node
target specifies targets for a shape.

"The following SPARQL query specifies the semantics of node targets. The
variable targetNode is assumed to be pre-bound to the given value of
sh:targetNode."  This also doesn't say how a node target specifies targets
for a shape.

"SPARQL DEFINITION
SELECT DISTINCT ?this    # ?this is the focus node
WHERE {
 BIND ($targetNode AS ?this)    # $targetnote is pre-bound to ex:Alice
}"  This also doesn't say how a node target specifies targets for a shape.

"A filter is a shape in the shapes graph that further refines which nodes in
the data graph are validated against a constraint or all the constraints of
a shape. A filter is specified as an object in a triple with sh:filterShape
as the predicate.  Only those nodes that successfully validate against all
the filters of a constraint or a shape become focus nodes for the constraint
or the constraints of the shape."  This doesn't say how filters interact
with targets.  It appears that filters do *not* filter out focus nodes that
come from parameters that have a shape as value, as the focus nodes in this
case are specified by the referring constraint.

"The subjects of these triples can be constraints or shapes."  This doesn't
mention expected type so the values of sh:filterShape may need explicit
typing.  In particular, the example in Section 2.3 would need to have an
explicit type triple.

"Note that during the validation against filter shapes, the targets of these
filters are ignored."  This means that the targets of any shape that is a
value for sh:filterShape are always ignored as that shape is a filter shape.

"The objects of triples with sh:property as predicate have
sh:PropertyConstraint as expected type."  "The values of sh:shape must be
IRIs or blank nodes. The expected type of these values is sh:Shape."  So a
property that is a value of both sh:property and sh:shape is both a property
constraint and a shape.  So
ex:s1 rdf:type sh:Shape ;
 sh:targetClass ex:Student ;
 sh:property ex:s2 .
ex:s0 sh:shape ex:s2 .
ex:s2 sh:predicate ex:p ;
 sh:class ex:Person .
would fail on
ex:i1 rdf:type ex:Student .

"The class sh:Shape is defined as rdfs:subClassOf sh:Constraint. Thus, every
shape is also a focus node constraint."  This doesn't follow.


Peter F. Patel-Schneider
Nuance Communications

Received on Friday, 11 November 2016 04:55:50 UTC