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

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.

Holger

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