Re: New test cases from Peter

Hi Peter,

the WG has discussed this scenario at length in the recent meeting and 
concluded that the definition of sh:property would benefit from 
clarification about what is supposed to happen if a node is reached 
twice. I have applied such a clarification today, see the new paragraph 
under the textual definition of sh:property. Maybe the wording is still 
not perfect, but the intent has always been that new nodes must be 
produced, and the same policy already applied for all other constraint 
components.

As a result of this, I have removed the test case that only produced a 
single result.

This does not mean that some implementations may not optimize this 
further. For example, some engines may group together multiple similar 
results, as we had discussed last year (for Dimitris's large scale use 
cases). But in order to pass the formal WG test, a compliant engine must 
at least have a *mode* in which it would produce all results.

Regards,
Holger



On 19/04/2017 0:02, Peter F. Patel-Schneider wrote:
> 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 Thursday, 20 April 2017 01:32:16 UTC