Re: Formal objection on closing of ISSUE-92

Hi Peter,

On 27/02/2017 22:01, Peter F. Patel-Schneider wrote:
> This is a revised formal objection to how ISSUE-92 was closed.  (I have fixed a
> couple of important typos in the example shapes graph and added prefix
> directives.)
>
>
> The closure resulted in the addition of sh:qualifiedValueShapesDisjoint and
> the following wording:
>
> TEXTUAL DEFINITION of Sibling Shapes
> Let Q be a shape in shapes graph G that declares a qualified cardinality
> constraint (by having a values for sh:qualifiedValueShape and at least one
> of sh:qualifiedMinCount or sh:qualifiedMaxCount). If G contains a shape p
> that has Q as a value of sh:property and also true as its value for
> sh:qualifiedValueShapesDisjoint, then the set of sibling shapes is defined
> as the set of all values of the SPARQL property path
> sh:property/sh:qualifiedValueShape starting at p minus the value of
> sh:qualifiedValueShape of Q itself. The set of sibling shapes is empty
> otherwise.
>
> TEXTUAL DEFINITION of sh:qualifiedMinCount
> Let C be the number of value nodes v where validating v against the shape
> $qualifiedValueShape produces no validation results and where validating v
> against each of the sibling shapes produces some validation results. A
> failure MUST be produced if the said validations of any of the value nodes
> has produced a failure. Otherwise, a validation result MUST be produced if C
> is less than $qualifiedMinCount. The constraint component for
> sh:qualifiedMinCount is sh:QualifiedMinCountConstraintComponent.
>
>
> First, the definition of sibling shapes is missing context.  It cannot be
> the case that there is a single set of sibling shapes for the entire shapes
> graph, as indicated in the definition.  The definition of sibling shapes
> needs to be contextualized in some way.  The only suitable contextualization
> appears to be to define the sibling shapes of a shape as that is the only
> context that is available for the definition of sh:qualifiedMinCount.

We have addressed this by updating the definition of sibling shapes to 
be contextualized "for the shape Q".

>
> However, this contextualization is not adequate.  The definition of sibling
> shapes depends not only on the shape itself but also on shapes that refer to
> the shape.  This results in several sets of sibling shapes which in turn
> leads to several possible meanings for a particular shape.
>
>
> Consider the following shapes graph:
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix sh: <http://www.w3.org/ns/shacl#> .
> @prefix ex: <http://example.org/> .
>
> ex:s2 rdf:type sh:NodeShape ;
>    sh:targetClass ex:C1 ;
>    sh:qualifiedValueShapeDisjoint true ;
>    sh:property ex:qs1 ;
>    sh:property ex:qs2 .
>
> ex:s3 rdf:type sh:NodeShape ;
>    sh:targetClass ex:C1 ;
>    sh:qualifiedValueShapeDisjoint true ;
>    sh:property ex:qs1 ;
>    sh:property ex:qs2 ;
>    sh:property ex:qs3 .
>
> ex:qs1 rdf:type sh:PropertyShape ;
>    sh:path ex:p1 ;
>    sh:qualifiedValueShape ex:sx1 ;
>    sh:qualifiedMinCount 1 .
>
> ex:qs2 rdf:type sh:PropertyShape ;
>    sh:path ex:p2 ;
>    sh:qualifiedValueShape ex:sx2 ;
>    sh:qualifiedMinCount 1 .
>
> ex:qs3 rdf:type sh:PropertyShape ;
>    sh:path ex:p3 ;
>    sh:qualifiedValueShape ex:sx3 ;
>    sh:qualifiedMinCount 1 .
>
> ex:sx1 rdf:type sh:NodeShape ;
>    sh:class ex:C1 .
>
> ex:sx2 rdf:type sh:NodeShape ;
>    sh:class ex:C2 .
>
> ex:sx3 rdf:type sh:NodeShape ;
>    sh:class ex:C3 .
>
> The sibling shapes of ex:qs1 are either { ex:sx2 } or { ex:sx2, ex:sx3 }.
> The meaning of ex:qs1 for the first set of sibling shapes is that there must
> be at least one value of ex:p1 that is a SHACL instance of ex:C1 but not of
> ex:C2.  The meaning of ex:qs1 for the second set of sibling shapes is that
> there must be at least one value of ex:p1 that is a SHACL instance of ex:C1
> but not of ex:C2 or ex:C3.  These are different meanings, and there is no
> way to choose between them.

We have addressed this by updating the definition of sibling shapes to 
be the set of allvalues <#dfn-value>of the SPARQLproperty path 
<#dfn-property-path>|sh:property/sh:qualifiedValueShape|for anyshape 
<#dfn-shape>in|ps|. This means that there are no longer multiple choices 
in the case above. Besides, we believe this is a rather artificially 
constructed example that is unlikely to happen in practice.

>
> Even if this problem is overcome, sh:qualifiedValueShapesDisjoint introduces
> a non-local aspect to validation in that it is no longer possible to
> determine the behaviour of a shape by examining its property values.

We have addressed this by moving sh:qualifiedValueShapesDisjoint from 
the parent shape into the property shape itself. While the evaluation of 
such QCRs still needs to look into sibling shapes, this situation is not 
different from sh:closed, where we already have a similar situation. The 
working group feels that the convenience of the syntactic shorthand is 
worth introducing another such non-local aspect.

>
>
> Every use of sh:qualifiedValueShapesDisjoint can be replaced with a simple
> change to the shapes involved.  This change eliminates the problems with
> sh:qualifiedValueShapesDisjoint and makes the meaning of the shapes involved
> clearer.  As sh:qualifiedValueShapesDisjoint adds no expressive power to
> SHACL, the problems with its definition dictate that it simply needs to be
> removed.  ISSUE-92 can be resolved by noting that this form of additive
> behaviour can be obtained using negation and conjunction.

The working group came to the conclusion that the syntactic sugar is 
important and decided to keep the feature in the spec.

The working group would appreciate if you could revisit whether your 
concerns are still valid, given the edits above. If you elect to keep 
the formal objection open, please update it with the remaining concerns.

Thanks
Holger