Comments on Draft #2

I didn't get as far yesterday evening as I hoped, but here are 
additional comments on the draft [1]:

*** Document ***

9. Profiles

*** kc ***

What I had failed to understand is that "profiles" in this sense are 
profiles that apply to SHACL engines, not to instance data. That is 
implied in "Profiles can be used to define controlled sub-dialects of 
SHACL..." but I might have caught on sooner (given my own bias about the 
term "profile") if the heading had been "SHACL Profiles". I'd find it 
even stronger if it read "SHACL Language Profiles" but the "L" already 
means "language" so some might object to that.

*** Document ***

Constraints are either global or local. Global constraints are executed 
when constraint checking is invoked on the whole graph, and may verify 
arbitrary conditions. Local constraints are evaluated against a given 
focus node (represented by the variable ?this in SPARQL). The focus node 
serves as starting point of property paths and other graph traversal 
algorithms. A shape describes a group of local constraints with the same 
focus node. Shapes may be arranged in a specialization hierarchy, 
allowing some shapes to further narrow down the constraints from other 
shapes. Current proposals for such specialization mechanisms include 
sh:extends and rdfs:subClassOf triples. The latter implies that the 
nodes of RDFS classes may also be
interpreted as shapes.

*** kc ***

- "... whole graph" -- This is going to be hard to define, I think: what 
makes any graph "whole?" I also think that global is going to have to be 
defined in terms of something other than a graph -- a definition of a 
global context will require something outside of the graph structure. 
This may also relate to the area that Arthur talked about when he talked 
about unlinked graphs. Some options I see as definitions of "global" 
scope are: received triples (to or from an API), and time or 
source-based selection (using provenance). I also have examples from the 
Dublin Core community where more than one graph is needed, for example 
where some needed vocabularies are stored separately, such that IRIs 
must be resolved to effect validation. (Usually these separate 
vocabularies are cached locally, but that shouldn't be relevant to the 
global definition.)

"Local constraints are evaluated against a given focus node (represented 
by the variable ?this in SPARQL)."
- Minor change, but for clarity I think this should read "(*as* 
represented by....)"

"Shapes may be arranged in a specialization hierarchy, allowing some 
shapes to further narrow down the constraints from other shapes. Current 
proposals for
such specialization mechanisms include..."
- It sounds to me like this is an area that needs further development. 
How confident are we that these proposed methods "work"? Does this need 
a note in the document?

*** Document ***

2.1
has note:
"sh:Info has also been suggested, but this would work best if there was 
a deterministic mechanism to identify constraints that need to be 
checked, so that Info constraints can be bypassed. Related to this, 
Dimitris also suggested we introduce sh:ValidationResult as a superclass 
of sh:ConstraintViolation."

*** kc ***

I don't understand about by-passing Info constraints. If a constraint is 
included in a SHACL document, is it not important enough to be checked, 
regardless of the level of the error? If a condition is not considered 
important that constraint should not be included in the particular 
validation application.

Dimitris says: "Users can optionally execute a validation requiring the 
reporting of a minimum security level (i.e. Error). In that case the 
execution engine will skip the execution of all shapes or shape 
properties that have a weaker security level than the one requested at 
the execution time" [2]

While this sounds like a good idea, it does require there to be an 
agreed ranking of errors that are included in SHACL, or a way to 
customize that ranking, and a way to inter-rank any local sub-classes of 
sh:ValidationResult. Because of how differently people might see the 
various errors, I'm skeptical that this ranking would work.

Also, I was unable to find where Dimitris suggests sh:ValidationResult, 
but I actually prefer that term to "ConstraintViolation." I don't see 
the need for a superclass if it would have only one subclass -- maybe 
Dimitris, you could explain here what you had in mind?

*** Document ***
4.1 Property Constraints (sh:property)

A property constraint is a constraint that defines restrictions on the 
values of a given property in the context of the focus node. Here, the 
focus node is the subject and the property is the predicate of relevant 
triples. The property sh:property can be used to link a shape with its 
property constraints.

*** kc ***
If property constraints are "in the context of the focus node", what is 
the focus node of a global constraint? If it is a single graph, then it 
doesn't seem to be global -- it's just another graph. (This harks back 
to Arthur's question about unlinked graphs, and to my comment about 
"whole graphs" above.)

kc
[1] http://w3c.github.io/data-shapes/shacl/
[2] 
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0011.html
-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 17 March 2015 17:04:04 UTC