Re: Formal objection on closing of ISSUE-92

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>
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:
>
> "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
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT