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

Re: shapes-ISSUE-160 (Generalize sh:valueShape): Shall we generalize sh:valueShape to sh:shape [SHACL - Core]

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 20 May 2016 07:31:02 -0700
To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
Message-ID: <e01d81ce-6687-dc14-efb9-1ba9a63712fd@gmail.com>
So there are several different descriptions of sh:valueShape.  How can one
determine which one is the basis for generalization without some

Your description below says that it is the other ones, which is fine, but that
was missing from the proposal.

peter


On 05/19/2016 04:05 PM, Holger Knublauch wrote:
> 
> On 20/05/2016 6:13, Peter F. Patel-Schneider wrote:
>> The idea behind this generalization is good, but there needs to be more
>> details in how the generalization works, particularly as the current
>> descriptive wording in the spec is quite explicit in that it works for
>> properties only:
>>
>> The property sh:valueShape can be used verify that all values of the given
>> property must have a given shape.
> 
> Of course the spec doesn't show not-yet-approved features, so how could this
> already be changed? But the details were already spelled out, if you read
> further down in 4.7.1 and look at the TEXTUAL DEFINITION
> 
> A validation result must be produced for each value node where validating the
> value node against the shape specified by |sh:valueShape| produces any
> validation results with severity |sh:Violation|. Afailure must be produced if
> the validation of any value node has produced a failure.
> 
> This is using the term <a>value node</a> which is defined to be either the
> property values or the focus node itself. Also the SPARQL query in that
> section follows the usual pattern, and the only generalization would be to use
> $this instead of ?object:
> 
> SELECT $this ?failure
> WHERE {
> 	BIND (sh:hasShape($this, $valueShape, $shapesGraph) AS ?hasShape) .
> 	BIND (!bound(?hasShape) AS ?failure) .
> 	FILTER (?failure || !?hasShape) .
> }
> 
> 
> All we need to add is to extend the sh:context of sh:valueShape to also
> include sh:NodeConstraint. And then, to reflect this generalization, rename it
> to sh:shape similar to how sh:class and sh:datatype are named. My proposal was
> brief because nothing else was needed - the rest could have been derived from
> the spec.
> 
> Holger
> 
> 
>>
>>
>>
>> peter
>>
>>
>> On 05/11/2016 04:31 PM, RDF Data Shapes Working Group Issue Tracker wrote:
>>> shapes-ISSUE-160 (Generalize sh:valueShape): Shall we generalize sh:valueShape to sh:shape [SHACL - Core]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/160
>>>
>>> Raised by: Holger Knublauch
>>> On product: SHACL - Core
>>>
>>> Currently sh:valueShape only applies to property constraints. However, this means that it cannot easily be used in cases like sh:or. Also, there is no reason not to allow it for NodeConstraints.
>>>
>>> PROPOSAL: Rename sh:valueShape to sh:shape, add sh:NodeConstraint to its context.
>>>
>>>
>>>
> 
Received on Friday, 20 May 2016 15:19:27 UTC

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