Re: Node vs focus node (Was: Re: shapes-ISSUE-181: SHACL conformance for partial validation reports [SHACL Spec])

Thanks, Dimitris. Here are some comments:

"typically a <a>SHACL instance</a> of <code>sh:Shape</code>"

- why "typically"? In a standard, I think it has to be either yes or no. 
Even if it is optional, "typically" is not appropriate language.

"A shape provides a collection of <a>targets</a>, <a>filters</a>, 
<a>constraints</a> and <a>parameters</a> of <a>constraint components</a>"

What is a collection? Also, does every shape have targets and filters 
and constraints? If not, which are optional? Can you have a shape with 
none of them? Can any be repeatable?

"Focus node: A <a>node</a> in the <a>data graph</a> that is validated 
against a <a>shape</a> is called a <dfn data-lt="focus node|focus 
nodes">focus node</dfn>."

This has the "validated" problem - Validation needs to be defined, 
especially because of the English language root "valid" which means 
something that is "true". I suggest taking a definition from the XML 
schema document.[1] Also note that the entry in the terminology that 
includes validation is 1) not a definition of any of the terms and 2) 
each term should be defined separately. By this I mean:

"Data Graph, Shapes Graph, Validation, Report, Result, Violation, Failure
SHACL defines what it means for an RDF graph, referred to as the data 
graph, to validate against an RDF graph containing shapes, referred to 
as the shapes graph. The result of validation is a validation report 
including validation results such as informational results, warnings and 
violations. Validation may also result in a failure, which is reported 
by a SHACL processor to indicate that a request could not be handled. 
Failures are not represented as part of the validation report, but 
through implementation-specific channels. Validation of a shapes graph 
against a data graph involves validating each shape in the shapes graph 
against the data graph. A node in a data graph is said to validate 
against a shape if validation of that node against the shape neither 
produces any validation results nor results in a failure."

Not one term is defined there.


On 10/4/16 8:20 PM, Dimitris Kontokostas wrote:
> Hi Karen,
> This is a work in progress but tries to define focus nodes better
> regarding 2.1
> maybe this also needs better wording but here's the explanation
> ex:shapeA
>   sh:targetClass ex:Foo.
>   sh:property [
>     sh:predicate ex:foo ;
>     sh:shape ex:shapeB;
>   ].
> ex:shapeB
>   sh:targetClass ex:Bar.
>   sh:property []
>  ...
> shapeB has 2 roles in this shapes graph
> 1) validate all instances of ex:Bar against ex:shapeB
> 2) serve as a nested shape for ex:shapeA
> in the latter (only) the focus nodes are provided by ex:shapeA and  the
> target of ex:shapeB is ignored

"nested shape" is not defined in the document. Nor do I see where it 
says that the target of ex:shapeB is ignored. I see it in this example, 
but I don't see it in the document. I may have missed it. However, I 
believe this may alter the definition of shape, since it means that 
there are two kinds of shapes - primary and nested, and there are 
different rules applied to them.

> we also write in the spec (2.1) :
>  While targets define the starting points of the validation process,
> some shapes may validate
> -    less focus nodes when a shapes defines filters, or
> -    additional focus nodes against different shapes, for example when
> referenced via sh:shape and sh:or.

This is what I was asking about - there is a "starting point" but the 
focus node may change when constraints are applied - that's what this 
says. But "for example" isn't enough. It needs to be defined 
unambiguously exactly what happens, and it must list all of the 
properties that can modify a focus node. Reading the above, though, I 
have the impression that you are speaking of targets, not focus nodes. 
It isn't a focus node until all of the criteria that can modify the 
target are applied and it is "validated".

I apologize, Dimitris, because this is all coming down on you, but quite 
honestly this document does not read as a specification for a standard. 
I agree with Peter that the language is way too loose, and that too many 
conditions are left undefined. I still find that the document is far 
from what I would expect as a standards document. As always, I am 
willing to put more work into it doing direct editing, but it is nearly 
impossible at this point to make all of the comments in email because 
they are too many.


> let me know if this helps and if possible, which parts are still unclear
> Thanks
> Dimitris
> On Tue, Oct 4, 2016 at 6:03 PM, Karen Coyle <
> <>> wrote:
>     Here's what I see as the offending sentence, which is also one that
>     Peter cited:
>     "The focus nodes may also be determined as
>     part of the validation of constraints that include references to shapes
>     using properties such as sh:shape and sh:or."
>     That is in the first paragraph of 2.0.
>     See:
>     (2.1) "Targets are ignored when a shape is processed as a nested
>     shape in shape-based constraint components (i.e. sh:shape), logical
>     constraint components (i.e. sh:or), filter shapes (sh:filterShape)
>     or, for SHACL Full, in the evaluation of the sh:hasShape SPARQL
>     function as defined in appendix A."
>     I'm not sure what "targets are ignored" actually means, unless it
>     means that the entire data graph is the target. If you ignore a
>     target, then what are you paying attention to? Or is the meaning
>     that sh:shape and sh:or extend the target? Where you do first
>     connect with the data graph if there is no target?
>     kc
>     On 10/3/16 8:16 AM, Karen Coyle wrote:
>         I still find the definition of focus node circular. The focus
>         node is
>         defined as (in terminology):
>         "A node in the data graph that is validated against a shape is
>         called a
>         focus node."
>         This essentially says: if it is validated against a shape, then
>         it is a
>         focus node.
>         But there is a focus node constraint that defines constraints on the
>         focus node. So now there is a constraint defined on a focus node
>         that
>         (as per the terminology) cannot exist until validation takes place.
>         Also note that in the validation section, the only mention of focus
>         nodes is in the validation report. There is no description of
>         using (or
>         creating) focus nodes in validation. Since the Targets section
>         does not
>         define focus nodes, only targets, they have not been defined
>         anywhere in
>         sections 2 or 3.
>         kc
>         On 10/2/16 11:35 AM, Dimitris Kontokostas wrote:
>             Hi Karen,
>             On Sun, Oct 2, 2016 at 6:54 PM, Karen Coyle
>             < <>
>             < <>>> wrote:
>                 Dimitris, the part of the spec we are talking about is the
>                 validation section. If Filters take place as part of
>             validation,
>                 then we should move them to the validation section. If
>             validation
>                 takes place after the filters are applied, then at that
>             point it is
>                 a focus node. My understanding (and I would like to hear
>             from
>                 others) is that the entire process of validation takes
>             place on
>                 focus nodes.
>             Section 2 describes shapes, targets, filters and
>             constraints, then
>             section 3 describes validation as well as the data graph,
>             shapes graph
>             and validation results.
>             All constructs described in section 2 are referenced in the
>             validation
>             definition but any feedback to restructure these sections is
>             more than
>             welcome.
>             Based on my understanding,
>             filters are of course part of the validation process but the
>             term focus
>             node is used when the nodes reach the constraints of the shape.
>             As I said, I do not have a strong opinion on this and would
>             be happy to
>             discuss this further during the next call or hear what
>             others have to say
>                 I'm also a bit concerned about that "iff" - while it is
>             a commonly
>                 known shorthand for "if and only if" it is not English
>             language and
>                 not universally known, so I think that "iff" should be
>             written as
>                 "if and only if" when used in a sentence. If the section
>             were in an
>                 abstract syntax then I think that "iff" would be
>             appropriate. This
>                 section is not that formal. I do find it used in W3C
>             documents when
>                 describing formal rules (see section 2.1 of the SWRL
>             document [1]).
>             I replaced iff according to your suggestion.
>             Thanks,
>             Dimitris
>             --
>             Dimitris Kontokostas
>             Department of Computer Science, University of Leipzig & DBpedia
>             Association
>             Projects:,,
>             Homepage:
>             <>
>             <
>             <>>
>             Research Group: AKSW/KILT
>             <>
>     --
>     Karen Coyle
> <>
>     m: 1-510-435-8234
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects:,,
> Homepage:
> Research Group: AKSW/KILT

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 5 October 2016 15:57:25 UTC