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

Received on Friday, 8 April 2016 23:38:28 UTC