From SPARQL Working Group
Thanks for your comments on the SPARQL 1.1 Update Last Call draft.
While the Working Group has considered existing implementation experience and the implement-ability of the update language in defining the update specification, the group is not inclined to discuss specific implementation strategies within the document. The SPARQL 1.1 Update language is designed to be used to update data within RDF graph stores, and the Working Group has identified many application scenarios that require the ability to delete data (in addition to inserting new data or doing both at once). The group agrees that updating large amounts of data may be time-consuming against very large data sets, but feels that implementation techniques to address this are beyond the scope of our charter and this specification. Please note that it is not unusual for query or update languages to give application the ability to execute operations that are very time consuming under certain conditions.
The Working Group intends to advance this specification to W3C Candidate Recommendation status and to call for implementations of the language, along with any experiences related to implementing the language that might be cause for concern in the design of the language. As you use and/or implement the update language, we'd of course welcome any feedback you have if there are parts of the language design that might change to address your concerns over large-scale deployments.
We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.
thanks, Lee On behalf of the SPARQL Working Group
All, This is a comment concerning the Last Call Working Draft 'SPARQL 1.1 Update' . It is clearly written and, AFAICT sound. However, I have an issue with it - more on the conceptual level. I tried to express my concerns in a blog post  and will do my best to summarise in the following. While the proposed update language - without any doubt - is perfectly suitable for 'small to medium'-sized setups, I fear that we will run into troubles in large-scale deployments concerning the costs for updating and deleting huge volumes of triples. Now, I wish I had experimental evidence myself to proof this (and I have to admit I don't have), but I would like the WG to consider to either include a section discussing the issue, or setting up a (non-REC Track) document that discusses this (which could be titled 'implementation/usage advices for large-scale deployments' or the like). I do feel strongly about this and would offer to contribute to such a document, if desired. I'd very much appreciate it if WG members would be able to point me to own experiences in this field (experiments or real-world deployments alike). Cheers, Michael (with my DERI AC Rep and RDB2RDF WG co-chair hat off)  http://www.w3.org/TR/2011/WD-sparql11-update-20110512/  http://webofdata.wordpress.com/2011/05/29/ye-shall-not-delete-data/