Re: Formal objection on closing of ISSUE-92

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, 27 February 2017 12:02:29 UTC