Re: some comments on SHACL editors' draft of 8 November

On 11/11/2016 14:55, Peter F. Patel-Schneider wrote:
> Comments on editors' draft of 8 November
>
> There are still serious problems with the description of the basic
> terminology and operation of SHACL.  Among other problems, it is unclear
> what a constraint or constraint component is, how constraints are validated,
> how targets are determined, when targets are used, and how focus nodes are
> determined.  There needs to be a complete and thorough examination of the
> document by the working group to check for problems in the definition of the
> basic notions underlying SHACL.
>
>
> Here are some specific problems that I noticed in a quick read of the first
> two sections of the document.
>
> "A constraint component is an IRI in the shapes graph."  However, most of
> the IRIs that are constraint components do not show up in shapes graphs.

I have switched to "A constraint component has an IRI".

>
> "A constraint is a node in the shapes graph".  The first example, in Section
> 1.4, talks about four constraints.  Three of these are obvious nodes in example
> shapes graph, but the node for the fourth is unclear.

Switched to "The shape itself is also a constraint on the focus nodes...".

>
> "The validation report is the result of the validation process".  Section
> 1.4 states that a particular graph *is* the result of validation, indicating
> that no additional information can be included in the validation report.
> How then can properties, like sh:name, that seem to have optional status be
> useful?

The intended interpretation of the spec is that the validation report 
graph may include other triples. Is there a specific sentence which 
excludes this possibility? I don't see such a sentence, esp not in 1.4.

>
> "Targets MUST be ignored when a shape is processed as a value of parameters
> of shape-based constraint components (i.e. sh:shape), logical constraint
> components (i.e. sh:or), or filter shapes (sh:filterShape)."  This notion of
> processing is not defined in the document.

Switched to "Targets MUST be ignored when a shape is *used in a 
validation process* as a value of parameters ... ".

>
> "A node target is defined with the sh:targetNode predicate. Each value of
> sh:targetNode can be an IRI or a literal. Each value of a node target
> defines a node to validate in the data graph."   This doesn't say how a node
> target specifies targets for a shape.

We have used similar prose for the other built-in target types, and I 
believe it's sufficiently clear with the additional sentence below:

>
> "The following SPARQL query specifies the semantics of node targets. The
> variable targetNode is assumed to be pre-bound to the given value of
> sh:targetNode."  This also doesn't say how a node target specifies targets
> for a shape.
>
> "SPARQL DEFINITION
> SELECT DISTINCT ?this    # ?this is the focus node
> WHERE {
>  BIND ($targetNode AS ?this)    # $targetnote is pre-bound to ex:Alice
> }"  This also doesn't say how a node target specifies targets for a shape.

I have added a sentence to all of these SPARQL queries: "All 
<a>bindings</a> of the variable <code>this</code> from the 
<a>solution</a> become target nodes."


>
> "A filter is a shape in the shapes graph that further refines which nodes in
> the data graph are validated against a constraint or all the constraints of
> a shape. A filter is specified as an object in a triple with sh:filterShape
> as the predicate.  Only those nodes that successfully validate against all
> the filters of a constraint or a shape become focus nodes for the constraint
> or the constraints of the shape."  This doesn't say how filters interact
> with targets.  It appears that filters do *not* filter out focus nodes that
> come from parameters that have a shape as value, as the focus nodes in this
> case are specified by the referring constraint.

I don't see why this specific paragraph that you quote needs to mention 
targets. Filters are independent from targets (or sh:shape constraints) 
- they always apply. I don't understand your point about the referring 
constraint. Maybe an example would help.

>
> "The subjects of these triples can be constraints or shapes."  This doesn't
> mention expected type so the values of sh:filterShape may need explicit
> typing.  In particular, the example in Section 2.3 would need to have an
> explicit type triple.

I don't see that connection. The sentence about the subjects is about 
the surrounding shape, e.g. ex:ExampleFilteredShape. You state that the 
values of sh:filterShape may need rdf:type triples. We also don't state 
that shapes or constraints need an rdf:type.

>
> "Note that during the validation against filter shapes, the targets of these
> filters are ignored."  This means that the targets of any shape that is a
> value for sh:filterShape are always ignored as that shape is a filter shape.

I believe "during the validation against filter shapes" makes this clear 
enough, but if you have specific suggestions on how to make this 
clearer, I'd be happy to integrate them.

>
> "The objects of triples with sh:property as predicate have
> sh:PropertyConstraint as expected type."  "The values of sh:shape must be
> IRIs or blank nodes. The expected type of these values is sh:Shape."  So a
> property that is a value of both sh:property and sh:shape is both a property
> constraint and a shape.  So
> ex:s1 rdf:type sh:Shape ;
>   sh:targetClass ex:Student ;
>   sh:property ex:s2 .
> ex:s0 sh:shape ex:s2 .
> ex:s2 sh:predicate ex:p ;
>   sh:class ex:Person .
> would fail on
> ex:i1 rdf:type ex:Student .

I think this is the same example as in:

https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0005.html

and I have responded there.

>
> "The class sh:Shape is defined as rdfs:subClassOf sh:Constraint. Thus, every
> shape is also a focus node constraint."  This doesn't follow.

I have dropped the "Thus, ".

You can review my edits at

https://github.com/w3c/data-shapes/commit/ec1ae4fdf03e8ed8e0330cf4c9f129b355f8620a

Please follow up where you consider these edits insufficient.

Thanks
Holger


>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>

Received on Monday, 14 November 2016 06:32:24 UTC