Hi Andy,
this is in response to the parallel thread. I honestly wasn't aware that
there remain open issues with UPDATE and thought that the best solution
was to bring back initial bindings. Your email seems to state that
INSERT DATA { ?param1 foaf:name ?param2 }
is problematic because it's not valid syntax. But why is this a show
stopper to restoring initial bindings for other updates? Isn't this just
a matter of expectation management? Of course any query that takes
initial bindings must also be valid syntactically - if the template
query is invalid then the template with bindings is also invalid.
This may be one of the advantages of the parameterized SPARQL strings -
it allows cases such as above because it sits before the string
compiler. Another advantage of that is that magic properties (property
functions) can be substituted while initial bindings don't recognize
those. But this should be in the hand of the developer to decide which
mechanism to use - the parameterized strings have their own
disadvantages and limitations too.
In a nutshell, I remain of the opinion that corner cases such as INSERT
DATA should not lead to dropping an otherwise useful feature for the
other 99% of use cases (we never use INSERT DATA for example, but have
hundreds of other UPDATEs). It is inconsistent to support initial
bindings for Query but not for Update.
Thanks,
Holger
On 8/10/2013 7:19, Andy Seaborne wrote:
On 08/08/13 00:02, Rob Vesse wrote:
On a related topic I looked at Holger's question around injecting
BNodes into SPARQL updates via ParameterizedSparqlString and it
doesn't work in the scenario he describes (an INSERT WHERE) if the
variable is used both in the INSERT template and WHERE since the
template mention is treated as a minting a fresh BNode. Either he
needs to use the BIND workaround discussed by yourself in another
thread (http://markmail.org/message/3lsnjq7yca4es2wb) which I suspect
is not workable for TQ OR we need to look at restoring initial
bindings for updates.
BIND will work - this is way it works for CONSTRUCT.
All Holger's examples are WHERE based.
I think restoring the feature is going to be the best option, the
documentation just needs to be really clear that initial bindings
only apply to the WHERE portion of updates and not more generally
since that is the only way they were used prior to the feature being
removed (I went back and looked at the ARW 2.9.4 code). We can
always look at expanding their scope later as we've discussed in the
past.
Just to be clear - this is restoring the WHERE based functionality for
update.
I think that is the way forward. I'd like to hear from Stephen about
the implications for streaming but, superficially at least, it does not
look too bad. The initial binding is applied to each DELETE/INSERT/WHERE
(and DELETE WHERE?), when it is evaluated as a query. The streaming is
most critical in the DATA parts.
There is a separate issue about <_:id> and anything reserialized and
sent over the network.
Andy
