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

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Mon, 11 Apr 2016 10:06:20 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <570AEA7C.20404@topquadrant.com>
On 9/04/2016 4:49, Peter F. Patel-Schneider 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.

Changed "both *as* a property constraint..." to "both *in* a property 

> What are sh:subject, sh:predicate, and sh:object for node constraints?

By default none of these have any values for node constraint, but this 
is left to the individual constraint components.

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

Fixed as suggested by Irene.

> The textual definition for sh:minCount does not indicate that the number is
> the number for a given focus node.

I don't think this is unclear.  It says "the number of value nodes is 
less than..." but we have previously already defined that "value nodes 
are the objects of the triples that have the focus node..."

Latest changes:



> 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 Monday, 11 April 2016 00:06:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:31 UTC