Re: a problem with shapes and constraints

Thank you for your feedback Peter, we will track this with Issue 211
https://www.w3.org/2014/data-shapes/track/issues/211

On Tue, Nov 29, 2016 at 2:07 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> Here is an example shape that illustrates one problematic aspect of the
> current design of SHACL.
>
> se:s1 rdf:type sh:Shape ;
>  sh:class ex:c ;
>  sh:property [ sh:class ex:c1 ;
>                sh:predicate ex:p1 ;
>                sh:property [ sh:class ex:c2 ;
>                              sh:predicate ex:p2 ] ] .
>
> This shape is legal but doesn't do what is expected.  Users will write
> shapes like it and be surprised by the result.  Writing the sections of the
> SHACL document that address the problem illustrated here and similar
> problems has required considerable effort in the working group and will
> need
> still more effort.
>
>
> There are two methods to fix this problem.
>
> The first method, which I have previously described, is to have the
> constraint components completely control the jump from one focus node to
> another.  In this method sh:property becomes a parameter for a new
> constraint component and loses its special status.  The values for this
> parameter are property constraints, which as now have a value for
> sh:predicate or sh:path but are also shapes.  The new constraint component
> does what is expected for property constraints.  The fact that its value is
> now also a shape is irrelevant, because it is the constraint components
> that
> matter.  The current parameters that take shapes, sh:not, sh:and, etc., can
> take shapes that are property constraints, but ignore the sh:predicate or
> sh:path value.  Again, it is the constraint component that is in control,
> not whether the parameter value is a shape or property constraint.  In this
> method the above example gives the expected results.
>
> The second method is to have the shape itself completely control the jump
> from one focus node to another.  In this method there is no need for
> sh:property at all.  A shape that has a value for sh:predicate or
> sh:property sets up new focus nodes and associated value nodes; a shape
> without either leaves the focus node and value nodes the same.  There is
> also no need for property constraints.  In this method the above example
> would be written as:
>
> se:s1 rdf:type sh:Shape ;
>  sh:class ex:c ;
>  sh:shape [ sh:class ex:c1 ;
>             sh:predicate ex:p1 ;
>             sh:shape [ sh:class ex:c2 ;
>                        sh:predicate ex:p2 ] ] .
>
> Both methods would also turn sh:sparql into a parameter for a new
> constraint
> component that evaluates the SPARQL query on the current value nodes.
>
>
> Both methods eliminate the special status and handling of sh:property and
> sh:sparql.  They both eliminate problems with nodes that are both shapes
> and
> propertyy constraints.  They both reduce the fundamental concepts of SHACL
> to shapes and constraint components.
>
> Neither method requires drastic changes to the SHACL document or to how
> SHACL is implemented.  Adopting either would result in a better design for
> SHACL and would actually reduce the amount of effect needed to produce a
> final version of the SHACL document.
>
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT