Re: On various syntax issues

On 05/19/2016 03:47 PM, Holger Knublauch wrote:
> 
> 
> On 20/05/2016 1:07, Peter F. Patel-Schneider wrote:
>> It seems to me that one of the goals of syntax simplification is to end up
>> with a simpler syntax.  One aspect of having a simpler syntax, to me, is
>> that constructs that intuitively make sense are permitted, particularly if
>> similar constructs are also permitted.
>>
>> 1/ Because existing property constraints can be conjoined, it should be
>> possible to conjoin existing shapes, like
>>
>> ex:s1 rdf:type sh:Shape ;
>>   sh:nodeKind sh:IRI ;
>>   sh:class ex:Citizen .
>>
>> ex:s2 rdf:type sh:Shape ;
>>   sh:property [ sh:predicate ex:child ;
>>            sh:class ex:Person ] .
>>
>> ex:s3 rdf:type sh:Shape ;
>>   sh:scopeClass ex:Person ;
>>   sh:filter [ sh:property [ sh:predicate sh:age ;
>>                  sh:minInclusive 18 ] ] ;
>>   sh:and ( ex:s1 ex:s2 ) .
>>                          
>> So sh:and is needed unless there is another simple way to achieve this.
> 
> This can be written using sh:shape (in case it gets approved):
> 
> ex:s3 rdf:type sh:Shape ;
>  sh:scopeClass ex:Person ;
>  sh:filter [ sh:property [ sh:predicate sh:age ;
>                 sh:minInclusive 18 ] ] ;
>  sh:shape ex:s1 ;
>  sh:shape ex:s2 .
> 
> So unless we want to create a sh:and as an alternative syntax aligning with
> sh:or, I don't think we need sh:and.

This new feature probably means that sh:and is redundant.  Whether it is a
good idea to have sh:or and sh:not without a matching sh:and is a separate matter.

>> 2/ If a boolean construct is allowed in one place it should be allowed in
>> similar places.
>>
>> Because disjunction is allowed in node constraints (shapes) it should also
>> be allowed in property constraints, like
>>
>> ex:s4 rdf:type sh:Shape ;
>>   sh:scopeClass ex:Taxpayer ;
>>   sh:property [ sh:predicate ex:dependent ;
>>            sh:or ( ex:s1 ex:s2 )

This may now be allowed.  The situation is a bit unclear because the
description of sh:or starts "SHACL supports a high-level syntax for
disjunctive constraints that can be used to test whether the focus node has at
least one out of several shapes." which does not work for (inverse) property
constraints.  There is similar language for sh:not and sh:and.

>>
>> Because disjunction of node constraint (shape) components is allowed so should
>> disjunction of property constraint components, like
>>
>> ex:s4 rdf:type sh:Shape ;
>>   sh:scopeClass ex:Taxpayer ;
>>   sh:property [ sh:predicate ex:dependent ;
>>            sh:or ( ex:s1 ex:s2 [ sh:minCount 5 ] ) ] .

This does not appear to be allowed.  ISSUE-135 is tracking whether (some)
constraints are allowed as arguments to sh:and/sh:or/sh:not but that doesn't
appear to even allow this useful and simplifying construction.

> Yes this extension of sh:or had been approved recently and the spec had been
> updated.
> 
> Holger
> 
>

Received on Friday, 20 May 2016 00:59:29 UTC