W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 2016

Re: Shapes and/vs constraints

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 14 Apr 2016 05:59:04 -0700
To: kcoyle@kcoyle.net, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <570F9418.5020407@gmail.com>
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
Received on Thursday, 14 April 2016 12:59:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:31 UTC