Re: SHACL syntax and metamodel complexity

My proposal is not about changing the expressiveness (or functionality) of
SHACL.  It is instead about cleaning up the syntax by making it more regular
and reducing the number of different syntactic entities.  This has the effect
of reducing the complexity of the metamodel as well, which is why I started
with this effort.

So instead of sh:Shape, sh:Scope, sh:scope, sh:Constraint,
sh:PropertyConstraint, sh:InversePropertyConstraint, sh:constraint,
sh:property, and sh:inverseProperty there is sh:Shape, sh:Component, and
sh:fillers.  Instead of a table showing which constraint constructs can fit
into which kind of constraint all components can fit into any shape.  Instead
of a complex process to determine which constraint components are present in a
constraint, all that is needed is to see if the component property has a value.

Any increase in functionality is a byproduct of this cleanup, except for the
ability to use paths in sh:fillers.  Currently only properties or their
inverses are allowed in the analogous constructs.


I am also trying some cleanup and refactoring on the non-core part of SHACL.
 Shapes are quite suitable for both checking whether a template invocation is
syntactically correct and for finding the template parameters.  This does away
with sh:Argument and its special subset of constraint components.

peter


On 03/05/2016 04:33 PM, Karen Coyle wrote:
> Is there anything else (upon a quick reading, of course) that differs between
> the two models (and by that I mean 1-current SHACL and 2-Peter's proposal) in
> terms of functionality? If so, I think we're in line for a comparative table
> between the two, so that we can more easily see the differences.
> 
> kc

Received on Sunday, 6 March 2016 20:35:44 UTC