Re: Shapes and/vs constraints

Karen Coyle <> wrote on 04/14/2016 10:35:49 AM:

> From: Karen Coyle <>
> To:
> 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 

Received on Thursday, 14 April 2016 16:32:13 UTC