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

On 28/05/12 13:36, Polleres, Axel wrote:
>> What do the definitions say?
>
> The current definitions that affect this behavior are
> 1) Dataset-UNION (df. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetUnion )
>   which does NOT standardize apart blank nodes
> and
> 2) Dataset( QuadPattern,  P, DS, GS ) (cf. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_datasetPattern)
>   which explicitly says that the scoping graph SG used for BGP matching is equal to the active graph,  i.e., blank nodes from the active graph are preserved in solutions.
>
> "Historically" when we did that, it was because we wanted to preserve bnodes in updates on the same graph.
>
> I.e., on
>
>    GS = {}
>      <g1>  { _:b :p :o }
>
> a request such as:
>
> update3 =
>   INSERT { GRAPH<g1>  { ?S :q :o } }
>   INSERT { GRAPH<g1>  { ?S :p :o } }
>
> should result in
>
>    GS' = {}
>      <g1>  { _:b :p :o ; :q :o }
>
> instead of
>
>    GS'' = {}
>      <g1>  { _:b :p :o . _:c :q :o }
>
> We didn't make any special assumptions about moving bnodes *across* graphs in the definitions for Dataset-UNION, and Dataset(),
> that is, in this sense I understand these definitions such that the result of update1 and update 2 (from the previous mails
> should be equivalent. Anything else, it seems to me, would need a modification of the Update semantics definitions.
>
> Now, there is some room probably of what we consider "equivalent" for datasets... and that might have to do with
> implementations... As Greg put it, he said that update1 would be idempotent, but he would return
> different bnode-ids, on update1, that was
>
> GS'''' = {}
>      <g1>  { _:b :p :o }
>      <g2>  { _:c :p :o }
>
>
> Question to greg here: is this because bnode-labels in greg's implementations are graph-specific? If so, and if these label
> renamings across graphs are round-trippable, then update 2 should probably also be idempotent, i.e. still the result would be
>
> GS'''' = {}
>      <g1>  { _:b :p :o }
>      <g2>  { _:c :p :o }
>
> Is that so?

No (I hope).

Greg - can you confirm that the problem is the way the results are 
specified, not test per se:


  mf:result [
                 ut:graphData [ ut:graph <insert-05-g1-pre.ttl> ;
                                rdfs:label "http://example.org/g1" ] ;
                 ut:graphData [ ut:graph <c> ;
                                rdfs:label "http://example.org/g2" ] ;
              ] ;

means read the file insert-05-g1-pre.ttl a second and third time, the 
first being in the mf:action.

So it generates different blanks nodes each time it's read, hence no 
shared bank node *in creating the results* -- nothing to do with the 
operation.

Hence either specify results in TriG/N_quads (but these are 
under-defined in this area) or make a conclusion that records the 
intended result and test for that (my long update request suggestion).

	Andy
>
> best,
> Axel (unfortunately probably not be able to dial in tomorrow being at ESWC)
> ________________________________________
> From: Andy Seaborne [andy.seaborne@epimorphics.com]
> Sent: Monday, May 28, 2012 11:47 AM
> To: Polleres, Axel
> Cc: public-rdf-dawg@w3.org; Gregory Williams
> Subject: Re: another update test added (was: RE: Questions on grammar restrictions  on Blank Node reuse across...)
>
> On 28/05/12 10:16, Polleres, Axel wrote:
>> 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?
>>
>
> What do the definitions say?
>
>          Andy
>
>> Best,
>> Axel
>>
>>
>>
>

Received on Monday, 28 May 2012 13:27:42 UTC