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

On 11/13/2016 10:31 PM, Holger Knublauch wrote:
> 
> 
> 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.

The following responses are about particular wording problems that I have
noticed.  They are not responsive to the general problem in the document
mentioned above.

>> 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".

Better.

>> "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...".

Better.

>> "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.

Yes, in the example there is the implication that one particular graph *is*
the result, none other.  These statements need to be softened to allow for the
presence of other information wherever that is possible.

>> "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 ... ".

What is "validation process"?  What does it mean for this process to use a
shape?  It would be much better to define validation as a mapping from, e.g.,
a shape graph and a data graph to a validation result without references to
processing and without uses of MUST.

>> "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:

This is not clear at all.  There is no notion of validation of a node in a
data graph without reference to a shape.  There is not even any mention that
the node becomes a target for the shape.

>> "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."

This fixes part of the problem.  This wording needs to be carried back to the
non-SPARQL definition.

>> "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.

As filters appear to have been removed this issue is moot.

>> "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.

No, but there are requirements on what is a shape or constraint in a shapes
graph.  If the requirements are not met then no SHACL processing will happen.
This particular instance of the situation appears to also be moot, but there
needs to be care taken throughout the document that the syntax supports the
required typing (SHACL or expected or whatever) that is required.

>> "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.

No.  Being a filter shape is something that is determined by the shapes graph.
 Validation against a filter shape then is independent of how the validation
is started.  For example, if a shape is a filter shape, then it cannot be used
to initiate validation even if it has targets.

To correct this systemic problem in the document, which is still present even
though this particular example is moot, requires moving away from the
processing-based description of validation to a description that includes a
definition of a relationship between nodes and shapes that doesn't involve
targets.  The description of filter shape processing would use this
relationship, which would not involve targets.

>> "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

peter

Received on Thursday, 17 November 2016 16:52:17 UTC