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

> 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.


But isn't this exactly what we ask for in the tests-README?
Cf.

> 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."


We ask here exactly for equivalence in the sense of http://www.w3.org/TR/rdf-concepts/#section-graph-equality (i.e. modulo bnode labels)... So if 05a works for an implementation, then 05 should work as well, shouldn't it?

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, 10 July 2012 11:17 AM
> To: public-rdf-dawg@w3.org
> Subject: 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 11:48:51 UTC