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

Dear all, 

I am a bit unsure/worried in the sense of what happens if I think this further...

Take this simple modification: 

update2 =  INSERT { GRAPH<g2>   { ?S ?P ?O } }
            WHERE { GRAPH<g1>   {?S ?P ?O } } ; 
           INSERT { GRAPH<g1>   { ?S ?P ?O } } 
            WHERE { GRAPH<g2>   {?S ?P ?O } }

Note now the second update copies back data from g2 to g1 instead of repeating the first update...
Would this second operation still be idempotent or not? 

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: Monday, 28 May 2012 11:12 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 26/05/12 16:01, Gregory Williams wrote:
> > On May 26, 2012, at 3:28 AM, Axel Polleres wrote:
> >
> >> As per
> >>
> >> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0165.h
> >> tml
> >>
> >>
> >>
> I added the test case corresponding to this one:
> >>
> >>>> 2) Do we agree that the semantics of
> >>>>
> >>>> update1 =  INSERT { GRAPH<g2>   { ?S ?P ?O } } WHERE {
> >>>> GRAPH<g1>   {?S ?P ?O } } ; INSERT { GRAPH<g2>   { ?S ?P ?O }
> >>>> } WHERE { GRAPH<g1>   {?S ?P ?O } }
> >>>>
> >>>> should be GS''
> >>
> >> now under:
> >>
> >> 
> http://www.w3.org/2009/sparql/docs/tests/data-sparql11/basic-update/i
> >> nsert-05.ru
> >>
> >>
> >>
> (since I have no implementation at hand to run it at the 
> moment, I'd appreciate feedback in case there's any issues)
> >
> > Do you think there's an automated way to test this? I ran 
> the new test 
> > against my engine, and it failed. Here's why:
> >
> > mf:result [ ut:graphData [ ut:graph<insert-05-g1-pre.ttl>  ; 
> > rdfs:label "http://example.org/g1" ] ; ut:graphData [ 
> > ut:graph<insert-05-g1-pre.ttl>  ; rdfs:label "http://example.org/g2"
> > ] ; ] ;
> >
> > When my test harness parses insert-05-g1-pre.ttl into the 
> two graphs, 
> > the bnode will be parsed twice, in two different contexts, yielding 
> > two different internal blank node labels (do we agree that 
> this is the 
> > expected behavior?). And so instead of comparing my actual results 
> > against
> >
> > GS'' = {} <g1>  { _:b :p :o } <g2>  { _:b :p :o }
> >
> > I end up comparing against something new:
> >
> > GS'''' = {} <g1>  { _:b :p :o } <g2>  { _:c :p :o }
> >
> > Which still succeeds at testing for the operation being idempotent, 
> > but has different bnodes in the two graphs.
> >
> > I'm not sure how to make this succeed except by manually 
> "fixing" my 
> > test results before submitting them (which I really don't 
> want to do).
> >
> 
> Agreed.
> 
> A way to test this is to add:
> 
> prefix : <http://example.org/>
> INSERT { GRAPH :g2  { ?S ?P ?O } }
>   WHERE { GRAPH :g1  { ?S ?P ?O } } ;
> 
> INSERT { GRAPH :g2  { ?S ?P ?O } }
>   WHERE { GRAPH :g1  { ?S ?P ?O } } ;
> 
> INSERT { :s :triplesInG2 ?count }
> WHERE
> {
>     { SELECT (count(*) As ?count)
>       {
>         GRAPH :g2  { ?S ?P ?O }
>       }
>     }
> } ;
> 
> INSERT { :s :matchesG1G2 ?count }
> WHERE
> {
>     { SELECT (count(*) As ?count)
>       {
>         GRAPH :g2  { ?S ?P ?O }
>         GRAPH :g1  { ?S ?P ?O } # Checks sharing.
>       }
>     }
> } ;
> 
> 
> DROP :g1 ;
> DROP :g2 ;
> 
> and check the default graph for counts of 1 and 1.
> 
> 
> 
> 
> > .greg
> >
> >
> 
>

Received on Monday, 28 May 2012 09:17:02 UTC