Re: on sh:qualifiedValueShapesDisjoint

I am unsatisfied by this response.

Peter F. Patel-Schneider
Nuance Communications

On 02/15/2017 03:54 PM, Holger Knublauch wrote:
> 
> 
> 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 Thursday, 16 February 2017 03:35:18 UTC