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: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 21 May 2016 09:47:21 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <ee5d44eb-a08f-23d7-ddc4-4e8bcb9ab516@topquadrant.com>
No. The proposal contained exactly the changes that were needed. No 
changes to the Textual or SPARQL definitions were needed. Your own 
Metamodel proposal has basically the same construct [1].

Anyway, we can hopefully make some progress next week.


[1] https://www.w3.org/2014/data-shapes/wiki/Refactor

  * sh:shape shape

        The nodes that validate are those that validate against the shape.

On 21/05/2016 0:31, Peter F. Patel-Schneider wrote:
> 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 23:47:55 UTC

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