W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > November 2016

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

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 12 Nov 2016 17:31:06 -0800
To: public-rdf-shapes@w3.org
Message-ID: <1db1b8c2-1c8c-1c5b-e71d-c89ecc12a46d@kcoyle.net>
I have added these to the page where we are keeping track of comments:


I realize that the short titles there do not do justice to the topics, 
but if some are just plain wrong, please let me know.


On 11/10/16 8:55 PM, 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.
> "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.
> "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?
> "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.
> "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.
> "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.
> SELECT DISTINCT ?this    # ?this is the focus node
> 	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.
> "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.
> "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.
> "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.
> "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 .
> "The class sh:Shape is defined as rdfs:subClassOf sh:Constraint. Thus, every
> shape is also a focus node constraint."  This doesn't follow.
> 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, 13 November 2016 01:31:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:46 UTC