Re: Comments on Draft #2

I believe global constraints have no focus node and this is what the word
Œglobalą means here - constraints that do not apply to any particular node
or a set of nodes. They apply to all data that is being subjected to the
validation process. It doesnąt mean that they apply to all data that
exists in the universe (as in Global with the capital ŒG˛), just any and
all data that one runs validation over.

It is a well understood word in the world of software development. If it
causes confusion, then we could try to pick another word. I think Holger
suggested Œstaticą.

On 3/17/15, 1:03 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>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.ht
>ml
>-- 
>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:29:08 UTC