Re: Shapes and/vs constraints

On 4/14/16 7:11 AM, Jim Amsden wrote:
> 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.

As I read SHACL, both shapes and constraints are classes, so the analogy 
to classes and properties doesn't fit for me. In fact, Peter's solution 
seems to be the one that follows the pattern of classes and properties. 
However, I admit that I never really "got" the reason for both 
constraints and shapes, and have assumed that there was an 
implementation motivation that wasn't obvious from the "user" view.

kc

>
> 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
>  >
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 14 April 2016 14:36:20 UTC