Re: strangeness of sh:qualifiedValueShapesDisjoint

Thanks for your comment. I see no new information in this email that you 
had not raised before, and I believe we had responded to these topics 
already.

Holger


On 21/03/2017 1:55, Peter F. Patel-Schneider wrote:
> The current definition of sibling shapes does not appear to have any
> structural problems.  However, sh:qualifiedValueShapesDisjoint does result
> in a very strange bit of syntax.
>
> This consruct was added very late to SHACL.  It does not appear to be needed
> for any use case for SHACL nor for any requirement for SHACL [SHACL Use
> Cases and Requirements, https://www.w3.org/TR/shacl-ucr/].  It does not add
> any expressive power to SHACL.  Any shape that uses the construct can easily
> be modified to an equivalent shape that does not use the construct.
>
>
> This construct will however cause problems for users of SHACL because it does
> not fit into the rest of SHACL.  With this construct the meaning of a
> constraint in a shape depends not just on the information attached to the
> shape but on information that references the shape.  So in
>
> ex:s1 rdf:type sh:PropertyShape ;
>    sh:targetClass ex:C1 ;
>    sh:path ex:p1 ;
>    sh:qualifiedValueShape [ sh:class ex:C2 ] ;
>    sh:qualifiedValueShapesDisjoint true ;
>    sh:qualifiedMinCount 1 .
> ex:s2 sh:property ex:s1 ;
>    sh:property [ sh:path ex:p2 ;
>                  sh:qualifiedValueShape [ sh:class ex:C3 ] ] .
> ex:s3 sh:property ex:s1 ;
>    sh:property [ sh:path ex:p2 ;
>                  sh:qualifiedValueShape [ sh:class ex:C4 ] ] .
>
> ex:s1 checks that all SHACL instances of ex:C1 have at least one value for
> ex:p1 that is a SHACL instance of ex:C2 and not a SHACL instance of ex:C3
> and not a SHACL instance of ex:C4.  To determine this requires looking
> outside of ex:s1 and into the shapes the refer to it and even into
> properties of shapes that do not form part of any of their constraints.
>
>
> As this construct does not add any expressive power to SHACL and any use of
> it can be easily removed it would be much better to eliminate all the
> complexities that it brings in by removing it.  Users who want disjointness
> of qualified value shapes can just use sh:and and sh:not, where there is no
> need to look outside the shape and which is easier to understand.
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Monday, 20 March 2017 21:48:53 UTC