Re: two interesting test cases for SHACL

On 11/14/2016 06:41 PM, Holger Knublauch wrote:

>> Further, this syntactic invalidity isn't particularly relevant to the actual
>> test.  se:s2 has expected type sh:PropertyConstraint, regardless of whether
>> the subject of the relevant triple is a shape or not.  The expectation is then
>> that se:s2 is a property constraint (although this is not explicitly mentioned
>> in the document).  Since se:s2 is a property constraint it acts like a
>> property constraint even when reached via sh:shape and thus produces the
>> validation report shown above.
> 
> No, the interpretation depends entirely on whether a constraint is reached via
> sh:shape vs sh:property. Only if reached via sh:property it will be
> interpreted as a property constraint. Which statements in the spec contradict
> this interpretation?

That doesn't correspond with the wording in the document.

"Property constraints specify conditions that must be met with respect to
nodes that can be reached from the focus node either by directly following a
given property (specified using sh:predicate) or a given property path
(specified using sh:path).  Property constraints are defined in a shape with
the property sh:property."

So a node in a shapes graph is a property constraint when it is the value of a
triple with predicate sh:property.  (Whether the subject of this triple has to
be a shape is unclear, but doesn't really matter.)

"sh:PropertyConstraint is the class of property constraints. The objects of
triples with sh:property as predicate have sh:PropertyConstraint as expected
type." says that every node with (SHACL?) type is a property constraint and
also hints that every object of a sh:property triple is a property constraint.

Consider the shapes graph

se:s1 rdf:type sh:Shape ;
  sh:property se:pc1 .
se:pc1 sh:predicate ex:p1 ;
  sh:class ex:c .
se:pc2 rdf:type sh:PropertyConstraint ;
  sh:predicate ex:p2 ;
  sh:class ex:c .

Both ex:pc1 and ex:pc2 are property constraints in this graph.  If the graph
also includes

se:s2 rdf:type sh:Shape ;
  sh:targetClass ex:c ;
  sh:shape se:pc1 ;
  sh:shape se:pc2

Then both se:pc1 and se:pc2 are still property constraints so the data graph

ex:i1 rdf:type ex:c ;
  ex:p2 ex:i2 .

will produce a validation report.

There is just one focus node for se:s2, ex:i1, which becomes the sole value
node.  There are two constraint parameter values to consider, se:pc1 and
se:pc2, both for parameter sh:shape.  So these two shapes end up with focus
node ex:i1.  The shape se:pc2 has one constraint parameter value, ex:c for
sh:class.  Because sh:pc2 is a shape, and thus a focus node constraint, the
focus node is checked (as value node) to see if it is a SHACL instance of
ex:c, which is the case.  However, sh:pc2 is also a property constraint so the
constraint component is also checked with focus node ex:i1 and value node
ex:i2, which produces a validation report.  Therefore se:s2 produces a
validation report.

Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 15 November 2016 03:30:21 UTC