withdrawing formal objection on closing of ISSUE-92

The definition of sibling shapes created in response to this formal objection
does not have any formal problems so I withdraw it.

Peter F. Patel-Schneider
Nuance Communications

On 02/27/2017 04:01 AM, 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.
> 
> 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.
> 
> 
> 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 Monday, 20 March 2017 15:53:30 UTC