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.

I have meanwhile updated the definition of QCRs to state that sibling 
shapes have a context "for shape Q". As you are resending your example, 
you may want to assess how serious your issue still is.

Note that there is at least one other example of inter-shape 
dependencies in SHACL Core: sh:closed. The main difference here is that 
sh:closed follows into property shapes from subject to object, while 
sh:qualifiedValueShapesDisjoint requires the engine to walk from object 
to subject too. Fundamentally they are very similar though, and RDF 
graphs are bidirectional.

The benefit of the syntactic sugar becomes more obvious in the common 
case where a shape does not use named QCRs, but each branch is a blank 
node. In those cases, users would need to multiply each blank node in 
the syntax in multiple sh:not branches, leading to completely 
unmaintainable code quickly.

So although I also don't like adding new complex features, I really do 
believe that this feature (or a variant of it) is very much needed in 
the "real" world and we would lose potential users.

Thanks,
Holger


>
> 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 }.
> 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, 27 February 2017 06:44:05 UTC