Re: Shapes and/vs constraints

I can see the potential simplicity and uniformity of merging Shape and 
Constraint (but in Peter's example, it would seem to make a lot more sense 
to use sh:cConstraint instead of sh:Shape). One possible outcome of this 
approach is that its fairly easy to describe constraints on a nested 
hierarchy or property navigation path.

However, RDFS and OWL clearly distinguish classes and properties of 
classes, and it seems reasonable for constraints to follow that 
distinction. The simplification below is significant, but I don't find it 
that compelling or sufficiently motivating to redesign SHACL. 

Rather the appeal of the current SHACL design is that it has real 
implementation and usage experience in OSLC Resource Shapes, and we don't 
introduce the risk of new unanticipated issues resulting from a different 
language for which we possibly can't reuse this experience.

Regarding that experience, I'm much more concerned that SHACL has no 
compatibility story with OSLC Resource Shapes. Given that there are 
significant implementations and existing products that have made 
investments in implementing and using Resource Shapes, it seems a prudent 
business (not technical) concern to address compatibility. It may be very 
hard to justify a business case for migrating those products to SHACL, 
possibly leading to barriers to its broad appeal and adoption.



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575


"Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 04/14/2016 
08:59:04 AM:

> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To: kcoyle@kcoyle.net, "public-data-shapes-wg@w3.org" <public-data-
> shapes-wg@w3.org>
> Date: 04/14/2016 09:00 AM
> Subject: Re: Shapes and/vs constraints
> 
> 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.
> 
> 
> 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.
> 
> 
> peter
>