Re: on sh:qualifiedValueShapesDisjoint

On 16/02/2017 1:27, Peter F. Patel-Schneider wrote:
> The recent addition of sh:qualifiedValueShapesDisjoint adds several negative
> aspects to SHACL.
>
> The definition of how sh:qualifiedValueShapesDisjoint works involves the
> term "parent", which is not defined.  This is yet another example of sloppy
> definition in the SHACL document.

The use of the term "parent" is outside of the textual definition and 
was chosen under the expectation that most people will intuitively 
understand what it means. There is no need to formally define every 
english word used by the spec.

>
> It used to be that it was possible to determine whether a focus node
> conformed to a shape by just looking at the information in the shapes graph
> reachable by following links in a forward direction.  With this change links
> have to be followed in a reverse direction as well.

While this is not ideal, the WG could not come up with a better solution 
to address the problem at hand. Walking triples in the reverse direction 
is not a problem for RDF based systems.

>
> The addition does not add any expressive power as it can be easily captured
> by using slighly more complex shapes as the values of
> sh:qualifiedValueShape.

The WG has decided that using more complex shapes will put too much 
burden on users, especially in cases where multiple complex qualified 
shapes are present. Building sets of sh:not constraints is too verbose 
and will not produce acceptable user experience.

>
> What happens when an involved shape is used in several shapes, as in:
>
> ex:S1 a sh:Shape ;
>    sh:targetClass ex:C1 ;
>    sh:qualifiedValueShapesDisjoint true ;
>    sh:property [
>      sh:path ex:p1 ;
>      sh:qualifiedValueShape [ sh:class ex:C2 ] ;
>      sh:qualifiedMinCount 1 ;
>      sh:qualifiedMaxCount 1 ;
>    ] ;
>    sh:property ex:S2 .
>
> ex:S2
>    sh:path ex:p1 ;
>    sh:qualifiedValueShape [ sh:class ex:C3 ] ;
>    sh:qualifiedMinCount 1 ;
>    sh:qualifiedMaxCount 1 .
>
> ex:S3 a sh:Shape ;
>    sh:property ex:s2 .
>
> It seems to me that ex:S3 checks for exactly one ex:p1 value that is a SHACL
> instance of ex:C3 and not a SHACL instance of ex:C2.

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.

>
>
> As this construct has problems and doesn't add any new capabilities there is
> no reason to retain it.

Disagreed. Among the costs of not including this feature is that some 
users will be attracted to other languages that do offer this 
capability, leading to a fragmentation of the language space.

Holger


>
>
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Wednesday, 15 February 2017 23:55:27 UTC