Re: Shapes and/vs constraints

Karen Coyle <kcoyle@kcoyle.net> wrote on 04/14/2016 10:35:49 AM:

> From: Karen Coyle <kcoyle@kcoyle.net>
> To: public-data-shapes-wg@w3.org
> Date: 04/14/2016 10:37 AM
> Subject: 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
> 
The fact that Shape and Constraint are both classes isn't really the 
point. Rather its how these classes are used to describe and/or validate 
graphs. Shape describes the collection of constraints on some class. 
Constraint is a component of a Shape that describes constraints on the 
properties of instances in scope.

So RDF Class corresponds to Shape, RDF Property corresponds to Constraint 
- at least to some extent.

Why do we need that? Possibly because classes and properties are different 
things and its useful to have different ways of describing constraints on 
them.