- From: Polleres, Axel <axel.polleres@siemens.com>
- Date: Tue, 10 Jul 2012 10:31:31 +0200
- To: "andy.seaborne@epimorphics.com" <andy.seaborne@epimorphics.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
> 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? > > 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. 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 08:32:09 UTC