- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 03 Jul 2012 16:47:38 +0100
- To: public-rdf-dawg@w3.org
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/insert-05a.ru > vs. > http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/insert-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/insert-05a.ru > also passes > http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/insert-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/insert-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). 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, 3 July 2012 15:48:11 UTC