- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 7 Nov 2016 10:52:40 -0800
- To: public-data-shapes-wg@w3.org
On 11/6/16 8:51 PM, Holger Knublauch wrote: > > > On 6/11/2016 6:44, Karen Coyle wrote: >> >> >> On 11/3/16 4:51 PM, Holger Knublauch wrote: >>> >>> >>> On 4/11/2016 2:20, Karen Coyle wrote: >>>> >>>> >>>> On 11/2/16 10:53 PM, Holger Knublauch wrote: >>>>> >>>>> >>>>> On 3/11/2016 14:36, Karen Coyle wrote: >>>>>> >>>>>> >>>>>> On 11/2/16 5:20 PM, Holger Knublauch wrote: >>>>>>> >>>>>>> >>>>>>> On 3/11/2016 0:48, Karen Coyle wrote: >>>>>>>> As decided at the meeting: >>>>>>>> >>>>>>>> On 10/28/16 9:39 AM, Karen Coyle wrote: >>>>>>>>> *QUESTION 1: What does it mean for a target to be "processed" as a >>>>>>>>> value? It's the term "processed" here that is problematic. >>>>>>>>> Perhaps an >>>>>>>>> example would help, and then we could tweak the language. >>>>>>>> >>>>>>>> Proposed: The target of a shape that is the value of another shape >>>>>>>> MUST be ignored. >>>>>>> >>>>>>> This isn't correct. This would also mean that target must be ignored >>>>>>> here: >>>>>>> >>>>>>> ex:PersonShape >>>>>>> sh:property [ >>>>>>> sh:predicate ex:address ; >>>>>>> sh:shape ex:AddressShape ; >>>>>>> ] . >>>>>>> >>>>>>> ex:AddressShape >>>>>>> sh:targetClass ex:Address . >>>>>>> >>>>>>> I have tried to explain before that this is a matter of context, >>>>>>> and it >>>>>>> only is ignored at validation time, not always. >>>>>> >>>>>> The spec has to define that context, and so far it doesn't. Please >>>>>> show an example of a target that would be ignored, and I will try to >>>>>> find appropriate wording. >>>>> >>>>> See the example above. Yes, we could put an elaborated example like >>>>> this >>>>> together with example instance data and validation results. The >>>>> problem >>>>> is that this is coming a bit early in the document - why should the >>>>> first example about targets be one that ignores targets. I also >>>>> honestly >>>>> don't think such a corner case deserves so much space. I think we >>>>> could >>>>> even delete the "Targets MUST be ignored..." paragraph because it >>>>> already follows as an implication from elsewhere. See the first >>>>> sentence >>>>> "A target provides *one way* to specify potential focus nodes...". >>>>> Other >>>>> ways include explicitly referencing a shape via sh:shape. So what >>>>> about >>>>> deleting the paragraph and adding something along the lines of what >>>>> Eric >>>>> suggested last night, to elaborate on other ways of finding focus >>>>> nodes >>>>> such as API calls? >>>> >>>> Holger, you have misunderstood my question. I am not asking for such >>>> an example to be added to the spec. I am asking for the example so >>>> that I can consider better wording. You say that the example above is >>>> one that should NOT be ignored. I am asking for an example of one that >>>> SHOULD be ignored, that illustrates the context you have cited. >>> >>> In the example above, the sh:targetClass statement is >>> >>> - ignored if the AddressShape is reached as part of the sh:shape >>> statement >>> - not ignored if the whole data graph is validated, i.e. the "standard >>> way" of using SHACL >> >> Neither this "context" nor what the phrase "standard way" represents >> are defined in the spec. This seems to go beyond what is defined in >> SHACL core, which is a language but does not include processing >> instructions that would govern the re-use or context for individual >> shapes. I don't find anything that would explain how, given the SHACL >> shape above, AddressShape would be reached via any route that is not >> part of the sh:shape statement. If there is a way, then we have >> something missing from the spec. if this information is essential, >> then additions to the spec are needed that would clarify the meaning. > > AddressShape is reached because validation of the data graph results in > validating each node that is in any target statement (see beginning of > section 3). The triple ex:AddressShape sh:targetClass ex:Address means > that it will be reached for any instance of ex:Address. Actually, I don't see that in section 3. This may be due to the confusion caused by the use of "validates". I think we should go over this in some detail, perhaps at the vf2f to clarify the language. When the text says: A node *validates* against a shape if and only if either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result or a failure for the node. does the first use of "validates" mean "is compared" or "is valid"? If it is the former, then we may need to say "is validated" rather than "validates". However, that doesn't make sense with the later clause in that sentence. I must say that within those three bullet points I find other areas of uncertainty which are hard to describe. Clarifying the meaning would make it possible to adjust the language. > >> >> As for including alternate entries to constraints, such as APIs, that >> might be resolvable with an issue. I'm hoping that it would be >> sufficient to have a statement in or around where focus nodes and/or >> constraints are defined to state that constraints act on focus nodes >> with no regard to how those nodes were determined; and that focus >> nodes can be defined with mechanisms that are external to the shapes >> graph. (Approximate wording!) > > This was the intention of the last bullet item in > > http://w3c.github.io/data-shapes/shacl/#dfn-focus-node > > * specified as input to the SHACL processor for validating specific > nodes from the data graph > <http://w3c.github.io/data-shapes/shacl/#dfn-data-graph> against the > shape > > This covers the cases in which targets are bypassed. I propose that this needs more than a single sentence in the focus node definition because it is a fundamental function of SHACL that is not otherwise obvious when reading the spec. Also, the examples should be consistent in whether they do or do not include the selection of focus nodes. This is something that is confusing throughout the document because sometimes the selection of focus nodes is included (e.g. in the constraint components section) and sometimes it is not (e.g. 2.3.1), but the examples are presented this way without explanation. It obviously makes sense to include targets in the section on targets. Whether they should be included in other sections needs to be consistent and explicit within each section. I believe this was what Ted and I were asking for at the last meeting. kc > > Holger > >> >> kc >> >>> >>> So if the shape is reached via sh:shape then the system does not test >>> whether the given value of ex:address is also an instance of ex:Address >>> (class). It could for example also be an untyped resource. sh:target >>> never behaves like a constraint. (filterShape does). >>> >>> HTH >>> Holger >>> >>> >>>> >>>> kc >>>> >>>>> >>>>> Anyway, now that I have given you an example, can you now rephrase the >>>>> paragraph about ignoring the target? >>>>> >>>>> Overall, we seem to continue to struggle with a different mindset >>>>> about >>>>> the role of the spec here. I believe you want it to be longer and more >>>>> instructive, while currently it's rather compact and just mentions the >>>>> facts. You do not like this, but my viewpoint remains that this >>>>> document >>>>> is not a tutorial. >>>>> >>>>> Holger >>>>> >>>>> >>>>> >>>>>> >>>>>> kc >>>>>> >>>>>>> >>>>>>>> >>>>>>>> (Alternate: The target *in* a shape... - I'm not sure what >>>>>>>> language we >>>>>>>> are using for the various components of shapes. It could be "The >>>>>>>> target that is a component of a shape ..." Any of those would be ok >>>>>>>> with me as long as we are consistent.) >>>>>>>> >>>>>>>>> >>>>>>>>> *QUESTION 2: Does "are" here mean "MUST"? (This is a question >>>>>>>>> throughout >>>>>>>>> the document, actually, wherever "are" is used in this way. >>>>>>>>> Perhaps we >>>>>>>>> can decide once for all.) >>>>>>>> >>>>>>>> >>>>>>>> Yes, MUST must be used here. >>>>>>> >>>>>>> I have switched to MUST. >>>>>>> >>>>>>> https://github.com/w3c/data-shapes/commit/06cd60457ec3448d7ca578c4aa3df324bea846f0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Could we close this ticket now? >>>>>>> >>>>>>> Holger >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 7 November 2016 18:53:16 UTC