Re: shapes-ISSUE-132 (sh:predicate in constraints): sh:predicate is used in many constraints but not always available [SHACL - Core]

I have to agree with Irene on that one. It's always better to make 
suggestions for improvements when reporting problems. If you're not sure 
what is intended, try to propose something that makes sense to you.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Cloud


Irene Polikoff <irene@topquadrant.com> wrote on 04/08/2016 04:37:51 PM:

> From: Irene Polikoff <irene@topquadrant.com>
> To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Holger 
> Knublauch <holger@topquadrant.com>, <public-data-shapes-wg@w3.org>
> Date: 04/08/2016 04:39 PM
> Subject: Re: shapes-ISSUE-132 (sh:predicate in constraints): 
> sh:predicate is   used in many constraints but not always available 
> [SHACL - Core]
> 
> Peter,
> 
> I think, it would save a lot of time and effort, if you just recommended
> the language for the passages. Otherwise, this goes into a lengthy,
> ineffective and antagonistic loop of ³this is not right, this is an
> improvement, but still some issues, this is better but not quite Š² and 
so
> on.
> 
> For example, instead of writing
> 
> Most of the descriptions read strangely.  For example, "The property
> sh:nodeKind can be used to restrict the node kind of all value nodes."
> What
> is the role of "all" here?  The first sentence for sh:class uses "each",
> which
> is much better.  Why is there a "can be" there?  Are there alternative
> validation uses for sh:nodeKind?
> 
> 
> 
> You could say
> 
> Please change this passage to:
> 
> "The property
> sh:nodeKind is used to restrict the node kind of each value node."
> 
> 
> Unless there are multiple possible validation uses of sh:nodeKind, ³is² 
is
> clearer than ³can be².
> 
> Regards,
> 
> Irene 
> 
> 
> 
> 
> 
> 
> On 4/8/16, 2:49 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> wrote:
> 
> >I assume you are referring to the changes at the beginning of the 
section
> >and
> >subsequent use of "value nodes". I am limiting these comments to parts 
of
> >this
> >bit that are relevant to ISSUE-132.
> >
> >There are some problems that probably can be fixed with a little 
editing.
> > The
> >constraint is the node that is the subject of the constraint component
> >triples.  This means that constraint components are not property
> >constraints
> >so the wording in and just before the first bullet list is incorrect.
> >
> >What are sh:subject, sh:predicate, and sh:object for node constraints?
> >
> >Most of the descriptions read strangely.  For example, "The property
> >sh:nodeKind can be used to restrict the node kind of all value nodes."
> >What
> >is the role of "all" here?  The first sentence for sh:class uses 
"each",
> >which
> >is much better.  Why is there a "can be" there?  Are there alternative
> >validation uses for sh:nodeKind?
> >
> >The textual definition for sh:minCount does not indicate that the 
number
> >is
> >the number for a given focus node.
> >
> >Overall this is a decided improvement, and appears to satisfactorily
> >address
> >ISSUE-132.
> >
> >
> >When reading through this section I noticed several problems and create
> >new
> >issues for them.
> >
> >peter
> >
> >
> >
> >On 04/07/2016 11:48 PM, Holger Knublauch wrote:
> >> I have meanwhile reworked chapter 3 so that it can be understood for
> >>all three
> >> contexts. Peter, could you check if this ISSUE-132 is now addressed?
> >> 
> >> Holger
> >> 
> >> 
> >> On 8/03/2016 10:03, Holger Knublauch wrote:
> >>> Yes, this aspect of the spec really needs a thorough update. The 
whole
> >>> structure still assumes Property Constraints only. I had been 
waiting
> >>>on the
> >>> resolution to the metamodel before cleaning this generalization up. 
I
> >>>had
> >>> put a red TODO block above the table in 3.1 to clarify this
> >>>construction site.
> >>>
> >>> Note that this chapter is work in progress to implement the 
resolution
> >>>to
> >>> ISSUE-98. In a nutshell, these constraint types can be used either 
at
> >>> sh:constraint (to apply to the focus node itself), at sh:property 
(to
> >>>apply
> >>> to all values of a given property), or at sh:inverseProperty (to 
apply
> >>>to
> >>> all inverse values of a given property). Which combinations are
> >>>supported is
> >>> summarized in the following table. The flow of the sub-sections 
needs
> >>>to be
> >>> adjusted and generalized accordingly.
> >>>
> >>> Holger
> >>>
> >>>
> >>> On 8/03/2016 9:51, RDF Data Shapes Working Group Issue Tracker 
wrote:
> >>>> shapes-ISSUE-132 (sh:predicate in constraints): sh:predicate is 
used
> >>>>in many constraints but not always available [SHACL - Core]
> >>>>
> >>>> http://www.w3.org/2014/data-shapes/track/issues/132

> >>>>
> >>>> Raised by: Peter Patel-Schneider
> >>>> On product: SHACL - Core
> >>>>
> >>>>
> >>>> The SHACL spec currently defines several constraints, including
> >>>>sh:class,
> >>>> with wording like
> >>>>
> >>>> **************
> >>>> A validation result must be produced for each triple that has the
> >>>>focus node
> >>>> as its subject, the sh:predicate as its predicate and where ...
> >>>> **************
> >>>>
> >>>> However, there might not be any predicate involved at all, for
> >>>>example where
> >>>> a sh:class is in a sh:constraint constraint in a shape that is
> >>>>invoked directly from a scope.
> >>>>
> >>>>
> >>>>
> >>>
> >> 
> >
> 
> 
>