Re: New test cases from Peter

It is entirely possible that implementations will want to evaluate constraints
in an optimized fashion.  This opens up the possibility that different
implementations will evaluate constraints different numbers of times.  For
example, a SHACL implementation might want to translate the shape in the
shared test into something like the following SPARQL query:

SELECT DISTINCT ?focus ?value ... WHERE {
  { { ex:i ex:p ?focus . } UNION { ex:i ex:q ?focus . } }
  ?focus ex:r ?value .
  FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* ex:C . }
  BIND ...
}

This then produces only one validation result for any node.


As this variation is allowable, the SHACL test methodology should check for it.


Peter F. Patel-Schneider
Nuance Communications




On 04/17/2017 06:31 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> thanks for the updates. I had to make a further correction to one of your
> files, which did not parse as valid Turtle. Meanwhile I have re-run my tests
> and updated the results, showing two failures:
> 
> 1) On the shared property shape test - we had discussed this topic before -
> and my interpretation remains that the report should contain the result twice.
> I have added a corresponding test case for that variation. Moving forward I
> see the following options:
> 
> a) The spec is clear
>     - that only one have to be produced (in which case variation 2 is removed)
>     - that two results have to be produced (in which case variation 1 is removed)
> b) The spec leaves the interpretation open (in which case we should not have a
> test case at all)
> c) The spec has an error and we need to make adjustments
> 
> I have no strong opinion either way and don't believe this scenario will
> happen often in practice.
> 
> 2) The pre-binding question is probably beyond what most people here
> understand so I have contacted Andy for his input.
> 
> I will put both topics on the agenda for the upcoming WG meeting.
> 
> Holger
> 
> 
> On 17/04/2017 23:36, Peter F. Patel-Schneider wrote:
>> On 04/16/2017 05:55 PM, Holger Knublauch wrote:
>>> Hi Peter,
>>>
>>> thanks for submitting 3 new test cases [1]. I made a couple of syntactic
>>> corrections which you can track on github. Among the more critical changes
>>> were:
>>>
>>> - the sh:value of the values.ttl test is ex:i, not 5, because the query does
>>> not return ?value and in that case the engine reverts to using the value node
>>> (which is the focus node in this case), see [2]
>> Yes, I forgot to set value.  Thanks for the fix, and the fix to
>> sh:sourceConstraint.
>>
>> I added another test where both $this and ?value are set from one VALUES
>> construct.
>>
>>> - I have deactivated the bind.ttl test case [3] because it is unclear what it
>>> is supposed to demonstrate. My current Jena-based engine returns no violation
>>> there, while your test seems to expect one violation. Could you explain the
>>> motivation for the test and the reason for your expected result?
>> This is a complex example.
>>
>> The empty BGP at the start of the query is removed because of the
>> simplification step 18.2.2.8 so $this is not bound at the beginning of the
>> query.  The SELECT * WHERE { } does not bind $this because $this is not
>> in-scope in it, even though $this has a value from the empty BGP in it.
>> Because $this does not have a value the BIND leaves ?that unbound.  Because
>> ?that is unbound, the BGP matches against the triple ex:j a ex:bad in the
>> data graph.  As there is a solution there is a violation of the shape.
>>
>> I modified the test to use ?value instead of ?that and to return ?value to
>> better utilize the behaviour of pre-binding.
>>
>>> - I have deactivated the shared.ttl test case [4] because it does not reflect
>>> the SHACL spec. The given validation result expects that the sh:node
>>> constraint is producing a violation with sh:ClassConstraintComponent as
>>> sourceConstraintComponent. However, the validation of sh:node (as explained in
>>> [5]) produces results with sh:NodeConstraintComponent as results. In other
>>> words, the results only report on conformance of the sh:node, and do not
>>> "walk" into it. Please feel free to submit an update to that test.
>> Yes, I was incorrectly thinking that sh:node constraints also reported their
>> component violations, not just an overall violation.  I have modified the
>> test to demonstrate the shared violation.
>>
>>> Regards,
>>> Holger
>>>
>>>
>>> [1]
>>>
>> https://github.com/w3c/data-shapes/pull/50/files/f857d2014900854ea1a0cf2ad498c9d0ae03cc0b..de60116e88470f51320e2442cce8698d7a44c6c8
>>
>>> [2] https://www.w3.org/TR/shacl/#sparql-constraints-variables
>>> [3]
>>>
>> https://github.com/w3c/data-shapes/tree/gh-pages/data-shapes-test-suite/tests/sparql/pre-binding
>>
>>> [4]
>>>
>> https://github.com/w3c/data-shapes/tree/gh-pages/data-shapes-test-suite/tests/core/validation-reports
>>
>>> [5] https://www.w3.org/TR/shacl/#NodeConstraintComponent
>>>
>>
>> peter
> 
>

Received on Tuesday, 18 April 2017 14:03:53 UTC