Re: Formal objection on closing of ISSUE-92

Thanks Dimitris. I must have misunderstood the meaning of the following:

> 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.

I read it as saying that the shortcut is not useful and should be dropped rather than trying to address any issues with it.

OK, with usefulness agreed on, my explanation of its utility may have been redundant, but the concluding question, I think, still stands:

> 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.

In other words, proposals to improve the current definition while retaining the usability.

Regards,

Irene


> On Feb 25, 2017, at 4:03 PM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> Dear Irene, Peter does not object on the possible usefulness of such a shortcut but on how it is currently defined
> 
> The objection refers to the corner cases Holger acknowledged in an earlier message:
> This is well-defined in the spec. Anyway, the scenario above is IMHO an artificially constructed corner case of no practical relevance. Our expectation is that QCRs will mostly be unshared blank nodes, similar to the example given in the spec.
> 
> On Sat, Feb 25, 2017 at 9:45 PM, Irene Polikoff <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
> 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 <mailto: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
>> 
> 
> 
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>