Fwd: Re: Formal objection on closing of ISSUE-92

Folks,

I have updated the definition of "sibling shapes" to make it clearer 
that they are computed based on *any* parent shape that has 
sh:qualifiedValueShapesDisjoint. I believe that covers the technical 
issues that Peter has raised in his objection.

Please double-check that the definition of sibling shapes is now 100% 
correct, see 4.7.3 of

     http://w3c.github.io/data-shapes/shacl/#dfn-sibling-shapes

I do believe that the scenario that he has created for his email is 
"artificially" constructed and would not happen in practice - I expect 
almost everyone will use blank nodes for such property shapes, and that 
they are not shared between parent shapes. But anyway, better err on the 
side of precision.

This does not address his point that the triple is not "local" to the 
shape. As I have pointed out this is already the case elsewhere (with 
sh:closed) so although a bit ugly this is a price that needs to be paid.

If we wanted to overcome that point too, an alternative design would be 
to pull the disjointness flag into each QCR branch. Our current example is:

ex:HandShape
 a sh:NodeShape ;
 sh:targetClass ex:Hand ;
 sh:qualifiedValueShapesDisjoint true ;
 sh:property [
  sh:path ex:digit ;
  sh:qualifiedValueShape [ sh:class ex:Thumb ] ;
  sh:qualifiedMinCount 1 ;
  sh:qualifiedMaxCount 1 ;
 ] ;
 sh:property [
  sh:path ex:digit ;
  sh:qualifiedValueShape [ sh:class ex:Finger ] ;
  sh:qualifiedMinCount 4 ;
  sh:qualifiedMaxCount 4 ;
 ] .

It would change to

ex:HandShape
 a sh:NodeShape ;
 sh:targetClass ex:Hand ;
 sh:property [
  sh:path ex:digit ;
  sh:qualifiedValueShape [ sh:class ex:Thumb ] ;
  sh:qualifiedMinCount 1 ;
  sh:qualifiedMaxCount 1 ;
  sh:qualifiedValueShapesDisjoint true ;
 ] ;
 sh:property [
  sh:path ex:digit ;
  sh:qualifiedValueShape [ sh:class ex:Finger ] ;
  sh:qualifiedMinCount 4 ;
  sh:qualifiedMaxCount 4 ;
  sh:qualifiedValueShapesDisjoint true ;
   ] .


This is very doable, i.e. not a big change to the spec. The downside is 
that it would need to be repeated with each QCR branch. I have no strong 
opinion and hope we can discuss this in the WG before I respond to Peter.

Regards,
Holger


-------- Forwarded Message --------
Subject:  Re: Formal objection on closing of ISSUE-92
Resent-Date:  Mon, 27 Feb 2017 12:02:32 +0000
Resent-From:  public-rdf-shapes@w3.org
Date:  Mon, 27 Feb 2017 04:01:45 -0800
From:  Peter F. Patel-Schneider <pfpschneider@gmail.com>
To:  public-rdf-shapes@w3.org



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