Re: Formal objection on closing of ISSUE-92

On 25/02/2017 14:45, Peter F. Patel-Schneider wrote:
> This is a formal objection to how ISSUE-92 was closed.
>
>
> 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.
>
> 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:
>
> 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:sx1 ;
>    sh:qualifiedMinCount 1
>
> ex:qs3 rdf:type sh:PropertyShape ;
>    sh:path ex:p3 ;
>    sh:qualifiedValueShape ex:sx2 ;
>    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 }.

ex:sx3 is not referenced by anything in your example. The example is not 
even valid Turtle. Please resubmit with those errors fixed.

Thanks,
Holger


> 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.
>
>
> 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.
>
>
> 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.
>
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Sunday, 26 February 2017 22:30:11 UTC