Re: Implement decision on bNodelabel/INSERT DATA operations.

We discussed this among the chairs and agree with Andy's position: the 
resolution was only intended to act on INSERT DATA/DELETE DATA, and so 
Andy's changes are appropriate.

Lee

On 10/5/2012 4:41 AM, Polleres, Axel wrote:
>> Context matters - a resolution was not presented before the meeting so
>> it was worded in the context of the meeting.
>> [...]
>> BNodes in templates behave differently.  Your proposed changes would
>> impact implementations more widely as well as potentially more widely on
>> existing update scripts.  We need to make minimal changes at this point.
> I think the wording of the resolution is unambiguous and wasn't proposing a change,
> but just to implement this wording. If we disagree here, then we probably
> have to discuss this again in the next Telco.
> (out of office with limited availability until Tue morning, sorry)
>
> It would be nice if the other implementers state their opinions here on the
> mailinglist beforehand.
>
> My understanding is that we agree on that
>     docs/tests/data-sparql11/basic-update/insert-data-same-bnode2.ru
>     (which doesn't show up in the CVS web interface, though), i.e.
> --------------------
> INSERT DATA { GRAPH :g1  { _:b :p :o } } ;
> INSERT DATA { GRAPH :g2  { _:b :p :o } } ;
> ...
> --------------------
>
>   should be disallowed following the resolution.
> IIUC, the case we disagree upon is:
>
>   docs/tests/data-sparql11/basic-update/insert-where-same-bnode2.ru
> i.e.
> --------------------
> INSERT  { GRAPH :g1  { _:b :p :o } } WHERE {};
> INSERT  { GRAPH :g2  { _:b :p :o } } WHERE {};
> ...
> --------------------
> which according to my reading of the resolution should turn into a negative syntax test, whereas
> Andy seems to disagree, correct?
>
> personal opinion: I personally think it would be more consistent to forbid both.
>
> Axel
>
>
>
> ________________________________________
> From: Andy Seaborne [andy.seaborne@epimorphics.com]
> Sent: Friday, October 05, 2012 12:12 AM
> To: Polleres, Axel
> Cc: public-rdf-dawg@w3.org
> Subject: Re: Implement decision on bNodelabel/INSERT DATA operations.
>
> On 03/10/12 16:05, Polleres, Axel wrote:
>> The resolution text is:
>>
>> "It's an error to use the same blank node label in two different operations in the same request."
>>
>> This resolution precludes also the use across two INSERTs (without DATA).
>> Probably it is simplest and least ambiguous to just stick to
>> that resolution wording, i.e., just replace
> As in my previous message:
>
> 1/ This does not address the context.
>
> Context matters - a resolution was not presented before the meeting so
> it was worded in the context of the meeting.
>
> 2/ Lack of evidence that any discussion was about templates despite one
> email having an example of it.
>
>> s/
>> The same blank node label can not be used in:
>>    * two basic graph patterns in a SPARQL Query
>>    * two WHERE clauses of SPARQL Update operations
>>    * two INSERT DATA SPARQL Update operations
>> /
>> The same blank node label can not be used in:
>>    * two basic graph patterns in a SPARQL Query
>>    * two different <a href="http://www.w3.org/TR/sparql11-update/#operation">SPARQL1.1 Update operations</a> in the same <a href="http://www.w3.org/TR/sparql11-update/#request">SPARQL1.1 Update request</a>.
>> /
>>
>> Does that work for you?
> BNodes in templates behave differently.  Your proposed changes would
> impact implementations more widely as well as potentially more widely on
> existing update scripts.  We need to make minimal changes at this point.
>
> Such bNodes get cloned before use so have no affect on bNodes placed in
> the graph store is happening (context).  The only difference is an
> update may now become syntactically illegal where previously it wasn't.
>
> Reconsidering this needs more than the discussion leading up to our
> resolution.
>
> ((Point of information:
> In ARQ, it is change in an unrelated area to the first one for INSERT
> DATA.  I can't not in all honesty keep making changes and still stand by
> my reported test results.
> ))
>
>> Best,
>> Axel
>>
>> P.S.: note that the case of two WHERE clauses within the same update operation (e..g by nested queries in the WHERE part of an update operation, is *somewhat* covered by the first bullet already, since these are 2 different BGPs in the same
>> "query part" of an update operation, so I don't think we need to mention this separately, but might want to clarify wording here, not sure it's necessary, though.
> More proposed changes and this time related to as this is
> CONSTRUCT+sub-query.
>
> If we are continuing to make changes and discuss this, then we aren't
> ready to go to PR.
>
> I am already uncomfortable enough about skipping CR.
>
>          Andy
>
>

Received on Friday, 5 October 2012 17:41:55 UTC