Re: Shapes and/vs constraints

On 14/04/2016 22:59, Peter F. Patel-Schneider wrote:
> On 04/13/2016 09:22 PM, Karen Coyle wrote:
>> One of the differences between the proposals put forth by Holger and Peter is
>> whether there need to be both shapes and constraints (Holger's view) or just
>> shapes (Peter's). This sounds to me like an important difference, but I need
>> an explanation of why 1) Holger thinks just having shapes will not work and 2)
>> why Peter thinks we do not need both.
>>
>> A simple, clear explanation of each point of view would be very much appreciated.
>>
>> Thanks,
>> kc
> The direct question is why doesn't SHACL *need* both shapes and constraints.
>
> The answer to this is that it is possible to unify both shapes and
> constraints in several ways.  Description logics (including OWL) provide one
> syntax design built around restrictions on objects and their property values
> that does not have a split between the analogue of shapes and constraints,
> using only classes.  The syntax that I put together a while ago also does
> not need both shapes and constraints to capture all the expressive power of
> the current core SHACL syntax.  Since it is possible to unify shapes and
> constraints in SHACL there is therefore no need for both of them.

Only because "you can" doesn't mean that "you should". And in this case 
"you can't" as enumerated in my previous email. Differences do exist.

>
>
> Given that it is possible to unify shapes and constraints, why is it a good
> thing to do?
>
> Consider a shape that validates nodes that are SHACL instances of ex:person
> and either doctors or have income greater than 100,000.  With split shapes
> and constraints this needs several constructs just to keep the split, as in
>
> ex:s1 a sh:Shape ;
>    sh:constraint [
>      a sh:NodeConstraint ;
>      sh:class ex:person ;
>      sh:or
>        ( [ a sh:Shape ;
>            sh:constraint [
>      a sh:NodeConstraint ;
>      sh:class ex:doctor
>      ]
>            ]
>          [ a sh:Shape ;
>       sh:property
>      [ a sh:PropertyConsraint ;
>        sh:predicate ex:income ;
>        sh:minExclusive 100000
>        ]
>    ] )
>      ] .
>
> With unified shapes and constraints these extra constructs are not needed,
> as in
>
> ex:s1 a sh:Shape ;
>    sh:class ex:person ;
>    sh:or
>      ( [ a sh:Shape ;
>          sh:class ex:doctor
>  ]
>        [ a sh:Shape ;
>         sh:propValues
>   ( ex:income
>     [ a sh:Shape ;
>         sh:minExclusive 100000
>       ]
>     )
>          ] ) .
>
> Not only is this shorter but it is more uniform.

This can be achieved by other means, as I have proposed by allowing 
sh:or to point at instances of sh:Constraint directly. This would be an 
incremental improvement that doesn't throw away all previous experience.

Holger

Received on Thursday, 14 April 2016 17:30:13 UTC