RE: Implement decision on bNodelabel/INSERT DATA operations.

> 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 08:41:51 UTC