Re: Formal objection on closing of ISSUE-92

Peter,

The working group received input that the use of negation and conjunction will not provide a satisfactory user experience. To quote https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0024.html <https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0024.html>:

"While qualified cardinality restrictions can capture top-level repeated properties, they become quite a burden to author and maintain. Likewise, exploding every OR with a negation of the DNF of the other disjuncts requires diligence and is tedious and error prone if the disjuncts have any complexity to them.”

There are a number of known use cases that require this feature. A simple example is “A person has to have either a value for a “full name” or values for a “first name” and “last name”, but these can’t be present together. 

This means that:

Graph 1

ex:Peter ex:firstName “Peter”.
ex:Peter ex:lastName “Patel-Schneider”.

passes validation

Graph 2

ex:Peter ex:fullName “Peter Patel-Schneider”.

passes validation

Graph 3

ex:Peter ex:firstName “Peter”.
ex:Peter ex:lastName “Patel-Schneider”.
ex:Peter ex:fullName “Peter Patel-Schneider”.

does not pass validation

There are many real life examples in life sciences and health care that require this feature and the conditions can grow large e.g., it is either property p1+p2 or property p3+p4+p5 or property p6. And there is also a separate condition that it is either p7 or p8+p9 and so on. 

As per above, for these use cases a combination of negation and conjunction is not seen as usable in practice. So, while sh:qualifiedValueShapesDisjoint may be seen as “syntactic sugar”, it is reported to be a necessary one.

We would be keen to hear any alternative ideas you may have on how to support these use cases in a way that will be practically usable.

Regards,

Irene



> On Feb 24, 2017, at 11:45 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> 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 }.
> 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
>