From SPARQL Working Group
Jump to: navigation, search

Draft response to

Hi Michael,

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


This is a comment concerning the Last Call Working Draft 'SPARQL 1.1  
Update' [1]. 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 [2] and will do my best to summarise in the  

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  

	Michael (with my DERI AC Rep and RDB2RDF WG co-chair hat off)