Re: another update test added (was: RE: Questions on grammar restrictions on Blank Node reuse across...)

On 10/07/12 09:31, Polleres, Axel wrote:
>> Correction:
>>
>> (2 separate read actions -> different bNodes -> can't be shared).
>>
>>        Andy
>
> So, doesn't this confirm my assumption that 05 and 05a essentially test the same thing?

If it were possible to write the necessary results for test 05 they 
could be made the same but the current manifest does not have correct 
results and it's impossible to write them.

The results described in the manifest do not show a shared bnode across 
graphs - you can not write that by reading in two graphs in two separate 
read operations.

ARQ passes 05 because ARQ only does graph isomorphism compare, not 
dataset isomorphism compare - it ought to fail but ARQ only has graph 
isomorphism checking code which is enough for all other tests.

>
>>> The problem with 05 is that the results do not sufficient constrain
>>> the results to ensure the test does indeed test for the
>> shared bnode.
>
> The test case doesn't test *shared* bnodes, but equivalence,
> G1 and G2 are two different graphs.

INSERT { GRAPH :g2  { ?S ?P ?O } }
  WHERE { GRAPH :g1  { ?S ?P ?O } } ;
INSERT { GRAPH :g2  { ?S ?P ?O } }
  WHERE { GRAPH :g1  { ?S ?P ?O } }

That shows that :g1 has all the triples of :g2 added twice.

By doing it twice it shows it is the same (identity equality).  But the 
results in the manifest write something different - :g1 and :g2 are two 
graphs with one triple but different bnode.  Isomorphic but not identity 
equivalent.

The file insert-05-g1-pre.ttl is read twice, which means 2 different 
bNodes.  So they are the right size and shape but do not express the 
identity relationship.

If, in the results you do

INSERT { GRAPH :g1  { ?S ?P ?O } }
  WHERE { GRAPH :XXX  { ?S ?P ?O } } ;
INSERT { GRAPH :g2  { ?S ?P ?O } }
  WHERE { GRAPH :XXX { ?S ?P ?O } }

then :XXX has two triples.

Hence failing the test is correct when dataset isomorphism is considered.

(aside from practical issues of not relying on who some toolkits 
actually treat bNodes labels when parsed in RDF)

05a capture the fact it is one triple directly and avoids the problems 
with the defined results.

 Andy


>
> Greg, any opinion on that?
>
> Best,
> Axel
>
> --
> Dr. Axel Polleres
> Siemens AG Österreich
> Corporate Technology Central Eastern Europe Research & Technologies
> CT T CEE
>
> Tel.: +43 (0) 51707-36983
> Mobile: +43 (0) 664 88550859
> Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com
>
>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
>> Sent: Tuesday, 3 July 2012 5:56 PM
>> To: public-rdf-dawg@w3.org
>> Subject: Re: another update test added (was: RE: Questions on
>> grammar restrictions on Blank Node reuse across...)
>>
>>
>>
>> On 03/07/12 16:47, Andy Seaborne wrote:
>>>
>>>
>>> On 03/07/12 16:31, Polleres, Axel wrote:
>>>> Addressing ACTION-656 and ACTION-642 (which are the same, I just
>>>> noticed...)
>>>>
>>>> When looking at
>>>>
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
>>>> nsert-05a.ru
>>>>
>>>> vs.
>>>>
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
>>>> nsert-05.ru
>>>>
>>>>
>>>> I ask myself the following:
>>>>
>>>> In
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/README.html#updateevaltests
>>>> we write:
>>>>
>>>>     "A SPARQL implementation passes a update evaluation test if the
>>>> graphs in the graph store are equivalent [RDF-CONCEPTS] to
>> the graphs
>>>> denoted in the mf:action property (and mf:result property,
>>>> respectively) prior to the update execution (after update
>> execution,
>>>> respectively). Equivalence can be tested as described
>> above for query
>>>> evaluation tests."
>>>>
>>>> Which, in my understanding, means that a test case that passes
>>>>
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
>>>> nsert-05a.ru
>>>>
>>>> also passes
>>>>
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
>>>> nsert-05.ru
>>>>
>>>> doesn't it? (since insert-05-g1-pre.ttl is graph equivalent to any
>>>> other graph using diferent blank node labels. Right?
>>>>
>>>> Thus, if I got that right, my suggestion would be to keep
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
>>>> nsert-05.ru (and probably add a reference to this email in the
>>>> description)
>>>>
>>>> Best,
>>>> Axel
>>>>
>>>> P.s.: note that the exact wording in
>>>>
>> http://www.w3.org/2009/sparql/docs/tests/README.html#updateevaltests
>>>> slightly differs at the moment... Some superfluous closing
>>>> parenthesis, essentially, only editorial. Will fix this
>> when I have
>>>> access to CVS again.
>>>>
>>>
>>> The problem with 05 is that the results do not sufficient constrain
>>> the results to ensure the test does indeed test for the
>> shared bnode.
>>>
>>> Each result graph is read in separately, generating bnodes.
>>>
>>> But the test is aimed at showing a sharing, which is not
>> possible to
>>> record by defining the graphs to read from file 92 separate read
>>> actions
>>> -> different bNodes).
>>
>> Correction:
>>
>> (2 separate read actions -> different bNodes -> can't be shared).
>>
>>        Andy
>>
>>>
>>> 05a solves this by adding an INSERT that works on the state of the
>>> graphs to record the result. It counts the triples and gets one
>>> showing the two inserts were the same triple, not different ones.
>>> Then it records the count in :g3, removes the troublesome g1 and g2
>>> then we can test for the state of g3.
>>>
>>>       Andy
>>>
>>
>>
>>
>

Received on Tuesday, 10 July 2012 09:17:56 UTC