Re: ISSUE-133: Wiki page with syntax examples

On 19/07/2016 16:17, Dimitris Kontokostas wrote:
>
>
> On Tue, Jul 19, 2016 at 3:35 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 18/07/2016 18:34, Dimitris Kontokostas wrote:
>>     In general I am in favor of syntax simplifications but I have
>>     some concerns on this one, mainly from the use perspective
>>     What might not be straightforward for the users with this
>>     proposal is that when they use sh:or in property constraints they
>>     will not be able to use components such as
>>     sh:hasValue, sh:equals, sh:disjoint, sh:min/maxCount, sh:uniqLang
>>     and in general all components with NC not checked in the table of
>>     section 4
>>     e.g. when someone defines that a property ex:p  must :
>>      - have sh:hasValue X or sh:hasValue Z
>>      - be sh:equals to ex:p1 or ex:p2
>>     they will always get back failures or violations (depending on
>>     ISSUE-139)
>
>     Let's try to get to the bottom of this.
>
>     In the current syntax the above would be expressed as
>
>     ex:MyShape
>         a sh:Shape ;
>         sh:constraint [
>             sh:or (
>                 [ sh:property [
>                     sh:predicate ex:p ;
>                     sh:hasValue X ;
>                 ] ]
>                 [ sh:property [
>                     sh:predicate ex:p ;
>                     sh:hasValue Z ;
>                 ] ]
>             ) ;
>         ] ;
>         sh:constraint [
>             sh:or (
>                 [ sh:property [
>                     sh:predicte ex:p ;
>                     sh:equals ex:p1 ;
>                 ] ]
>                 [ sh:property [
>                     sh:predicte ex:p ;
>                     sh:equals ex:p2 ;
>                 ] ]
>             ) ;
>         ] .
>
>     i.e. the sh:or must be placed on the outside. With the new syntax
>     that situation does not change, only that the sh:constraint
>     triples would be collapsed:
>
>     ex:MyShape
>         a sh:Shape ;
>         sh:or (
>             [ sh:property [
>                 sh:predicate ex:p ;
>                 sh:hasValue X ;
>             ] ]
>             [ sh:property [
>                 sh:predicate ex:p ;
>                 sh:hasValue Z ;
>             ] ]
>         ) ;
>         sh:or (
>             [ sh:property [
>                 sh:predicte ex:p ;
>                 sh:equals ex:p1 ;
>             ] ]
>             [ sh:property [
>                 sh:predicte ex:p ;
>                 sh:equals ex:p2 ;
>             ] ]
>         ) .
>
>     Using sh:hasValue and the other operators inside of an sh:or at a
>     property constraint would not have the desired effect, because
>     sh:or iterates over all values of the property and then applies
>     the constraint independently. And the members of the sh:or list
>     are sh:Shapes, not sh:NodeConstraints.
>
>     But this topic seems orthogonal to the question of merging
>     sh:NodeConstraint with sh:Shape to me. Could you clarify where you
>     see the connection?
>
>
> I agree that if you know how you want to do something the new syntax 
> will make it easier for you.
> but if we merge sh:Shapes with with sh:NodeConstraints, we will make 
> it very natural for people to express shapes in a wrong way, i.e. 
> write it like
>
> ex:MyShape
>     a sh:Shape ;
>     sh:property [
>         sh:predicate ex:p ;
>         sh:or (
>             [sh:hasValue X ;]
>             [sh:hasValue Y ;]
>        ) ;
>         sh:or (
>             [sh:equals ex:p1 ;]
>             [sh:equals ex:p2 ;]
>        ) ;
> ] ;
>
> and it will be harder for us to explain why the former is wrong while 
> the following is correct
>
> ex:MyShape
>     a sh:Shape ;
>     sh:property [
>         sh:predicate ex:p ;
>         sh:or (
>             [sh:datatype ex:d1 ;]
>             [sh:datatype ex:d2 ;]
>        ) ;
>         sh:or (
>             [sh:class ex:c1 ;]
>             [sh:class ex:c2 ;]
>        ) ;
> ] ;
>
> imho If we keep the sh:constraint (or sh:node) explicit in the 
> definition it will be easier to explain the difference

I agree with this aspect. Whether it's a strong enough argument is 
unknown. In general I believe this topic is quite hard to answer as 
anticipating all consequences is barely possible without practical 
experience with more scenarios and users.

Holger