Re: two interesting test cases for SHACL

On 15/11/2016 13:29, Peter F. Patel-Schneider wrote:
>
> 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.

You are interpreting the spec so that sh:shape would treat its values as 
both property constraints and node constraints/shapes. But the 
definition of sh:shape states

Avalidation result <#dfn-validation-results>must be produced for 
eachvalue node <#dfn-value-nodes>where validating the value node against 
the shape specified by|sh:shape|produces any validation results.

To me, the "against the shape" narrows it down to shapes. The validation 
of shapes is defined in the beginning of section 3:

  * Anode <#dfn-node>validates against ashape <#dfn-shape>if and only if
    either it does not validate against somefilter <#dfn-filter>of the
    shape or none of theconstraints <#dfn-constraint>in the shape
    produce avalidation result <#dfn-validation-results>or afailure
    <#dfn-failure>for the node.

If this leaves the loophole that a shape may be interpreted as a node 
constraint (which isn't the intention), then I have just added the 
following sentence:

Note that validation against a shape processes the shape as afocus node 
constraint <#dfn-focus-node-constraints>only, even if the shape may 
have|rdf:type|triples or anexpected type <#dfn-expected-type>that would 
also make themproperty constraints <#dfn-property-constraints>.

Does this sufficiently clarify the situation?

Thanks,
Holger