W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > November 2016

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

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Thu, 3 Nov 2016 19:08:52 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <40c9fc91-e9aa-e39a-f73a-425398e3885c@kcoyle.net>


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>"

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 Friday, 4 November 2016 02:09:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 November 2016 02:09:30 UTC