Re: shapes-ISSUE-193 (Focus nodes): Targets can be refined; focus nodes do not change

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