Re: eliminating property constraints

Peter, I have edited the page of received comments [1] and have created 
issues for as many of the items that I could. I would love to say that 
it is all complete and correct, but am not so confident. If you have 
time to review the list and the newly raised items on tracker,[2]  I 
would appreciate it.

kc
[1] https://www.w3.org/2014/data-shapes/wiki/Comments/September2016/
[2] https://www.w3.org/2014/data-shapes/track/issues/raised

p.s. for Arnaud - the missing issue #206 is because I had created a 
duplicate, which I then deleted

On 11/19/16 6:08 AM, Peter F. Patel-Schneider wrote:
> SHACL currently has shapes, constraints, constraint components, parameters,
> and the special property sh:property.  This leads to a complex formalism
> that the SHACL document continues to struggle to adequately describe.
>
> This complexity is not necessary.  Both shapes and constraints can be merged
> into a single notion of shapes.  The special property sh:property can be
> turned into the single parameter of a new constraint component.
>
> Under this new setup for SHACL shapes are uniformly validated in a context
> where there are focus nodes and value nodes.  Shape validation from targets
> is done in a context for each target node with the focus node being the
> target node and the set of value nodes being the singleton containing only
> the target node.  Constraint components in a shape are each validated in the
> context of the shape.
>
> The new constraint component, with parameter sh:property, works by
> validating its shape argument in a new context for each value node of the
> current context.  This new context has as its focus node the original value
> node and has as its value nodes the set of value nodes for the sh:property
> or sh:path in the shape, just as before.
>
> This change is largely just a change in the description of SHACL.  There
> are, however, a few minor changes to SHACL itself.  First, there would be a
> new constraint component with sh:property as its sole parameter.  Second,
> the argument for this parameter would be a shape, albeit one that has to
> have a value for either sh:predicate or sh:path.  It would be possible make
> the expected type for sh:property values be a subclass of sh:shape, but
> users of SHACL would not need to know that this was the case and the only
> reason to do so would be to support the validation of SHACL shapes graphs in
> SHACL.
>
> This change to SHACL would help greatly in decreasing the complexity of the
> langauge and permit a better and more streamlined description of SHACL.
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>

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

Received on Sunday, 20 November 2016 21:30:01 UTC