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 Thursday, 4 October 2012 22:12:48 UTC