- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 8 Nov 2016 09:09:19 +1000
- To: public-data-shapes-wg@w3.org
On 8/11/2016 4:52, Karen Coyle wrote: > > > 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"? It means "is valid". Nothing depends on the fact whether a node has been compared against a shape. > > 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. Maybe all this will be addressed with your suggestion to switch to "successfully validate"? > >> >>> >>> 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. Can someone (Eric?) suggest such a sentence? Holger > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >
Received on Monday, 7 November 2016 23:09:54 UTC