Re: on focus nodes

On Tue, Oct 11, 2016 at 9:09 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

>
>
> On 10/11/2016 10:43 AM, Dimitris Kontokostas wrote:
> > There is no single diff for that change but you can look here
> > https://github.com/w3c/data-shapes/compare/gh-pages@%7B10-
> 03-2016%7D...gh-pages
> >
> > On Tue, Oct 11, 2016 at 7:54 PM, Peter F. Patel-Schneider
> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> >
> >
> >     So now focus nodes are mentioned (in the Constraint and Constraint
> Component
> >     terminology sections and in Section 1.4) well before there is
> >     any statement of what a focus node is.  So, no, I don't think that
> this
> >     looks good to me.
> >
> >
> > We are in the process of moving most of the terminology sections on the
> main
> > sections so the reference there will be removed shortly
> > Despite that, we cannot remove all forward references in the spec, e.g.
> > validation is defined in section 3 and mentioned before
>
> I don't have access to plans for the document, so I can only look at its
> current state.  Having me try to figure out whether some bit of the current
> state is going to be changed in the future is a waste of my time.  I
> suggest
> not asking for my comments when there are relevant changes that remain to
> be
> done unless there is some specific wording that is being pointed out.
>

During a recent telco we decided to have a single place to define terms in
the spec and this would be the respective section for every term.
This avoids definition duplication, which resulted in many external
comments.
Thus, we cannot avoid the forward references in section 1 (and possibly
other places in the spec)


> >     There is still also the problem that Section 2 appears to state that
> there
> >     are four separate ways to determine the set of focus nodes of a
> shape.
> >
> >
> > Is this incorrect or is there another problem here?
>
> Either or both.
>
> The wording indicates that the set of focus nodes of a shape can be
> determined
> by targets and filters.  This would then determine the set of focus nodes
> and
> the other possibilities could not then change the set of focus nodes.
> Similarly for the other three ways of determining the set of focus nodes
> of a
> shape.
>
> I don't think that this is the right way for SHACL to work (and I don't
> think
> that this is the way that SHACL used to work), but I don't know whether
> this
> is the way that the working group intends SHACL to work.
>
> I expect that SHACL hasn't changed and that this is yet another example of
> poor definitions in the SHACL document.
>

Trying to identify the wrong definition since we did not change the way
SHACL works the last few months.
 - Are there less or more ways to make a node a focus node?
 - Does the current wording implies that the ways to determine the set of
focus nodes of a shape cannot be combined?
 - Do we need to define this like a sequence process (as suggested by Irene)
 - Do we need to define / align this with validation steps (as suggested by
Karen)

If you have any suggestions for an alternate wording we would definitely
take it into account.

Thanks,
Dimitris

-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT