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

Re: shapes-ISSUE-146 (sh:qualifiedMinCount ): treatment of unbound results from sh:hasShape in sh:qualifiedMinCount (and elsewhere) [SHACL - Core]

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 22 Apr 2016 14:43:50 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <5719AC06.6030108@topquadrant.com>
Ok, I think I start to get it :)

The same inconsistency applied to sh:valueShape which I have also 
updated here:

https://github.com/w3c/data-shapes/commit/d5c7708c820ce87a21625e849a79d3059fd15a84

Both cases should IMHO propagate any nested failures.

Thanks,
Holger


On 21/04/2016 20:53, Peter F. Patel-Schneider wrote:
> The handling of ?failure in general is not the issue here.  The issue is that
> the textual definition indicates that a failure results when there are too few
> values for which the shape produces no violation-level validation results or
> failures.  However, the code does not add failures to the count but instead
> propagates them.
>
> peter
>
>
> On 04/21/2016 02:33 AM, Holger Knublauch wrote:
>> The updated version of the spec clarifies the handling of the ?failure variable.
>>
>> Sigh, we really need more test cases to make sure we are agreeing on the right
>> thing...
>>
>> Then, in this particular case I am not sure whether QCRs will remain in the
>> spec at all, given that we have the sh:partition proposal.
>>
>> Holger
>>
>>
>> On 15/04/2016 4:10, Peter F. Patel-Schneider wrote:
>>> The text indicates that errors are counted, but the code appears to propagate
>>> them.
>>>
>>> peter
>>>
>>>
>>> On 04/10/2016 04:23 PM, Holger Knublauch wrote:
>>>> I believe the query is correct, but I have added a paragraph to make it a bit
>>>> clearer:
>>>>
>>>> Note that in the SPARQL query above, we assume that the |SUM| operation fails
>>>> if one of the values of |?s| is not a number. This mechanism is used by the
>>>> error handling, which sets |?s| to the string |'error'| whenever one of the
>>>> individual |sh:hasShape| calls fails.
>>>>
>>>> HTH
>>>> Holger
>>>>
>>>>
>>>> On 9/04/2016 7:11, RDF Data Shapes Working Group Issue Tracker wrote:
>>>>> shapes-ISSUE-146 (sh:qualifiedMinCount ): treatment of unbound results
>>>>> from sh:hasShape in sh:qualifiedMinCount (and elsewhere) [SHACL - Core]
>>>>>
>>>>> http://www.w3.org/2014/data-shapes/track/issues/146
>>>>>
>>>>> Raised by: Peter Patel-Schneider
>>>>> On product: SHACL - Core
>>>>>
>>>>> It's hard to determine just what is going on in the SPARQL code, but
>>>>> appears that if any call to hasShape returns unbound then a validation
>>>>> result will be produced, which does not match the text.
>>>>>
>>>>>
>>>>> TEXTUAL DEFINITION of sh:qualifiedMinCount
>>>>> A validation result must be produced if the number of triples that have
>>>>> the focus node as its subject, the sh:predicate as its predicate and where
>>>>> validating the object against the shape specified by
>>>>> sh:qualifiedValueShape produces no validation results with severity
>>>>> sh:Violation or a failure is less than sh:qualifiedMinCount. The produced
>>>>> validation result must have the focus node as its sh:subject, and the
>>>>> sh:predicate as its sh:predicate.
>>>>> SPARQL DEFINITION of sh:qualifiedMinCount
>>>>>
>>>>> SELECT $this ($this AS ?subject) $predicate ?failure
>>>>> WHERE {
>>>>>      {
>>>>>          SELECT (SUM(?s) AS ?count)
>>>>>          WHERE {
>>>>>              {
>>>>>                  FILTER NOT EXISTS { $this $predicate ?value } .
>>>>>                  BIND (0 AS ?s) .
>>>>>              }
>>>>>              UNION
>>>>>              {
>>>>>                  $this $predicate ?value .
>>>>>                  BIND (sh:hasShape(?value, $qualifiedValueShape,
>>>>> $shapesGraph) AS ?hasShape) .
>>>>>                  BIND (IF(bound(?hasShape), IF(?hasShape, 1, 0), 'error')
>>>>> AS ?s) .
>>>>>              }
>>>>>          }
>>>>>      }
>>>>>      BIND (!bound(?count) AS ?failure) .
>>>>>      FILTER IF(?failure, true, ?count < $qualifiedMinCount) .
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
Received on Friday, 22 April 2016 04:44:27 UTC

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