- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 7 Nov 2016 10:10:38 -0800
- To: public-data-shapes-wg@w3.org
All good, thanks. - kc On 11/6/16 8:37 PM, Holger Knublauch wrote: > > > On 4/11/2016 12:08, Karen Coyle wrote: >> >> >> On 11/3/16 5:48 PM, Holger Knublauch wrote: >>> >>> >>> On 4/11/2016 2:28, Karen Coyle wrote: >>>> >>>> >>>> On 11/2/16 11:44 PM, Holger Knublauch wrote: >>>>> >>>>> >>>>> On 3/11/2016 14:34, Karen Coyle wrote: >>>>>> >>>>>> >>>>>> On 11/2/16 6:31 PM, Holger Knublauch wrote: >>>>>>> >>>>>>> >>>>>>> On 28/10/2016 2:50, RDF Data Shapes Working Group Issue Tracker >>>>>>> wrote: >>>>>>>> shapes-ISSUE-193 (Focus nodes): Targets can be refined; focus >>>>>>>> nodes do >>>>>>>> not change >>>>>>>> >>>>>>>> http://www.w3.org/2014/data-shapes/track/issues/193 >>>>>>>> >>>>>>>> Raised by: Karen Coyle >>>>>>>> On product: >>>>>>>> >>>>>>>> Focus nodes are defined as "A node in the data graph that is >>>>>>>> validated >>>>>>>> against a shape is called a focus node." >>>>>>>> >>>>>>>> Section 2. further defines focus nodes like this: >>>>>>>> >>>>>>>> "The set of focus nodes for a shape may be identified as follows: >>>>>>>> >>>>>>>> *specified in a shape using targets and filters, >>>>>>>> *specified in any constraint that references a shape in >>>>>>>> parameters of >>>>>>>> shape-based constraint components (i.e. sh:shape) or logical >>>>>>>> constraint components (i.e. sh:or), >>>>>>>> *specified as input to the SHACL processor for validating specific >>>>>>>> nodes from the data graph against the shape, or >>>>>>>> >>>>>>>> Shapes can also provide non-validating information, such as labels >>>>>>>> and >>>>>>>> comments." >>>>>>>> >>>>>>>> (That last sentence is a non sequitur because the section is about >>>>>>>> focus nodes only.) >>>>>>>> >>>>>>>> Section 2.1 says: >>>>>>>> >>>>>>>> "2.1 Targets >>>>>>>> >>>>>>>> A target provides one way to specify potential focus nodes for a >>>>>>>> shape." >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> "Not all target nodes become focus nodes. When a shape includes >>>>>>>> filters, filters can remove nodes specified by targets from the >>>>>>>> set of >>>>>>>> the shape’s focus nodes." >>>>>>>> >>>>>>>> This seems to state that the nodes specified by targets ARE focus >>>>>>>> nodes. I would end this after "targets" in the second sentence. >>>>>>> >>>>>>> Done: >>>>>>> https://github.com/w3c/data-shapes/commit/c1855ed19630c9262bbe058e7880887e86dc56dd >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Then, section 2.2 says: >>>>>>>> >>>>>>>> "2.2 Filter Shapes >>>>>>>> >>>>>>>> A filter is a shape in the shapes graph that further refines the >>>>>>>> focus >>>>>>>> nodes in the data graph that are validated against a constraint or >>>>>>>> all >>>>>>>> the constraints of a shape." >>>>>>>> >>>>>>>> Again, this says that there are focus nodes that are refined - but >>>>>>>> above it seems to say that only the actual nodes that are validated >>>>>>>> are focus nodes. Instead, filters act on targets, not focus nodes. >>>>>>> >>>>>>> No, filter shapes *do* act on focus nodes, not (only) on targets. >>>>>>> Filters are *always* evaluated, even if a shape is "directly" >>>>>>> referenced, e.g. by ShEx-style targetless invocation or when they >>>>>>> are a >>>>>>> result of sh:shape only. >>>>>> >>>>>> This is what contradicts the definition of focus nodes. On the one >>>>>> hand, only nodes that are actually validated are focus nodes. On the >>>>>> other, focus nodes exist before filters are applied, since filters >>>>>> can >>>>>> act on them. So the question is: when is a focus node "born"? If a >>>>>> focus node is something that can be further refined with a filter, >>>>>> then the original definition is not correct because there are focus >>>>>> nodes that are not the final validation node, since filters (which I >>>>>> assume are not validations) can further refine them. >>>>>> >>>>>> Again, the statement in 2. is: >>>>>> "A node in the data graph that is validated against a shape is called >>>>>> a focus node." >>>>>> >>>>>> That defines focus nodes as "those that are validated against a >>>>>> shape." >>>>>> >>>>>> Then the definition for targets says: >>>>>> "Not all target nodes become focus nodes. When a shape includes >>>>>> filters, filters can remove nodes specified by targets." This doesn't >>>>>> mention focus nodes, and seems to me to be correct. >>>>>> >>>>>> This was my original question, and it goes something like this: >>>>>> >>>>>> Possibility A: >>>>>> >>>>>> Apply a target = focusNode1 >>>>>> Apply a filter to focusNode1 = focusNode2 >>>>>> Apply a constraint to focusNode2 = focusNode3 >>>>>> >>>>>> Possibility B: >>>>>> >>>>>> Apply a target = targetResult >>>>>> Apply a filter to targetResult = filterResult >>>>>> Apply a constrain to filterResult = focusNode >>>>>> >>>>>> In other words which of these are focus nodes? From the >>>>>> definition, it >>>>>> seems like only the final nodes, after targets, filters, and >>>>>> constraints are applied, are focus nodes. But you seem to be >>>>>> referring >>>>>> to an "intermediate" focus node. I think that focus node should be >>>>>> reserved for the final selected node that is validated. >>>>> >>>>> The first sentence of the Targets section states >>>>> >>>>> A target provides one way to specify *potential* focus nodes. >>>>> >>>>> Maybe "potential focus nodes" would be a term to use for the >>>>> "intermediate" filterResult nodes that are in between targets and >>>>> focusNodes? >>>> >>>> OK, so you do consider the intermediate results to be focus nodes that >>>> will be further refined? In that case, the statement that focus nodes >>>> are defined as nodes that are validated against a shape appears to be >>>> in contradiction with that, and we have a moving target in the term >>>> "focus nodes". >>>> >>>> >>>> I still suggest that the term "focus node" be used only for the final >>>> result, and the intermediate steps not be given any specific name. So >>>> the result of applying a target is simply a node, and that may or may >>>> not become the focus node for the comparison process. So a target >>>> identifies a node in the data graph. That's all. Then a filter may >>>> filter that result. Some constraints (still undefined, I believe) can >>>> be applied to the filter result. After all of this is completed, a >>>> focus node has been identified. >>> >>> Does this change set reflect this: >>> >>> https://github.com/w3c/data-shapes/commit/003db0c5b3f8a172a4158f88d474bc75662a2207 >>> >>> >>> >>> If not, please point at other specific lines in the document where our >>> use of "focus node" does not match your expectations. >> >> Thanks. So, if we are indeed going to limit "focus nodes" to the final >> outcome, then there are a few more changes in the core (sections 1-4) >> section. In 3-4, there aren't problems - once the spec talks about >> validation, the focus node concept is clear. >> >> 526 "# Elements highlighted in blue are focus nodes that are >> # selected by some target of a shape under discussion >> # and validate against the shape's filters, if any." >> >> I think this means to say: >> >> # Elements highlighted in blue are focus nodes that have been >> # selected by a target of a shape and any filters >> # that refine the targeted node. >> >> Line 927 has typo "focus nodes" should be "focus node" >> >> Comment on line 1008: >> "that further refines the nodes in the data graph that are validated >> against a <a>constraint</a> or all the constraints of a <a>shape</a>" >> - I don't think it refines the nodes in the data graph - I think it >> refines the definition of which nodes will be validated. So it could >> change to: >> >> "that further refines *which* nodes in the data graph that are >> validated against a <a>constraint</a> or all the constraints of a >> <a>shape</a>" > > Done > > https://github.com/w3c/data-shapes/commit/1f4008a00970762adb6dad98e5660e9fcd65bba1 > > > (I went with a less redundant # comment in line 526 - hope that's OK). > > As this was a purely editorial ticket and you seemed to be OK with the > changes, I have closed ISSUE-193. Please reopen if you disagree. > > Thanks > Holger > >> >> Comment on line 1011: >> "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." >> - I'm not sure what the distinction is here between filters of a >> constraint vs. filters of a shape, especially because shapes are of >> class sh:Constraint. I believe that "constraint" here refers to >> section 2.3 and the properties defined in section 4, but this is >> confusing because they have the same name as sh:Constraint. I suspect >> this may be a separate issue for the spec, and it could be a big one. >> It may be worth creating an issue for. >> >> I still have lots of editorial changes to suggest that crop up >> whenever I read the text, but I want to get through the "validation" >> issue first. I should have something very simple for that in the next >> day or two, then I'll move on to other issues. >> >> kc >> >>> >>> Thanks >>> Holger >>> >>> >>>> >>>> kc >>>> >>>> >>>> >>>>> >>>>> Note that an engine may push the evaluation of the filters into the >>>>> validation itself. Each filterShape can be translated into an >>>>> equivalent >>>>> sh:or. So a SPARQL query that is produced from a constraint that has a >>>>> filter may simply have a SPARQL FILTER at the beginning, before the >>>>> actual body of the query starts. This blurs the lines between those >>>>> stages quite a bit. Some implementations may indeed do the >>>>> filtering as >>>>> a pre-processing step, others may treat them just like focus nodes and >>>>> do the filter as part of the constraint execution. >>>>> >>>>> I did a search for "focus node" across the current document I don't >>>>> see >>>>> a specific contradiction of our use of that term. Is there still a >>>>> specific problem left? >>>>> >>>>> I also wonder how we can get feedback about this whole feature. >>>>> This WG >>>>> seems to continue to struggle with the filter shape concept. We still >>>>> have the option to replace it with a sh:disabled true flag. The WG is >>>>> far from representative of the potential user group. If external >>>>> people >>>>> struggle with this feature, we may do the adoption of SHACL a >>>>> disservice >>>>> if we over-complicate it. >>>>> >>>>> 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:11:19 UTC