- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 12 Nov 2016 17:31:06 -0800
- To: public-rdf-shapes@w3.org
I have added these to the page where we are keeping track of comments: https://www.w3.org/2014/data-shapes/wiki/Comments/September2016/#November.2C_2016 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. kc 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. > > "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. > > "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