Re: Formal objection on closing of ISSUE-92

Oops, yes you are right.  I'll submit a revised version.

Thanks,

peter


On 02/26/2017 02:29 PM, Holger Knublauch wrote:
> 
> 
> 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.
>>
>> 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 }.
> 
> ex:sx3 is not referenced by anything in your example. The example is not even
> valid Turtle. Please resubmit with those errors fixed.
> 
> Thanks,
> Holger
> 
> 
>> 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 Sunday, 26 February 2017 22:39:40 UTC