- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 03 Jul 2012 16:56:10 +0100
- To: public-rdf-dawg@w3.org
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/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). 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, 3 July 2012 15:56:39 UTC