Re: ACTION-575: Propose tests for ADD, MOVE, and COPY

On Jan 20, 2012, at 4:12 PM, Matthew Perry wrote:

> Hi,
> 
> I added some SPARQL Update shortcut tests in /add /move and /copy.

I have some concerns about the affects of (non-)atomicity on some of these tests. I'm going to discuss the copy05 test, but suspect this issue applies to several others as well.

In copy/manifest#copy05, the test seems to rely on the atomicity of the request. Here are the details:

######## Query <copy-05.ru>
PREFIX : <http://example.org/>
COPY SILENT :g4 TO :g1


######## Default graph <copy-default.ttl>
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix :      <http://example.org/> .
:ron a foaf:Person .
:ron foaf:givenName "Ronnie" .
:ron foaf:mbox  <mailto:ronnie@example.org> .



######## Graph <http://example.org/g1> (from <copy-01.ttl>)
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix :      <http://example.org/> .
:jerry a foaf:Person .
:jerry foaf:givenName "Jerry" .
:jerry foaf:mbox  <mailto:jerry@example.org> .


The update document says that this COPY operation "is equivalent to" the operation:

DROP SILENT :g1 ; INSERT { GRAPH :g1 { ?s ?p ?o } } WHERE { GRAPH :g4 { ?s ?p ?o } }

First, I don't think this is actually true, because the text also says "by default, the service SHOULD return failure if the input graph does not exist," which I believe makes this not directly "equivalent to" the INSERT version (which would just DROP :g1 and then leave it empty).

Second, it's not clear to me whether COPY is a single operation, or two operations (a DROP followed by an INSERT). This is an important distinction, because operations are defined to be atomic, but the atomicity of a request of multiple operations is only RECOMMENDED. For systems that don't support atomic, multi-operation transactions on their underlying graphstore, it seems natural to me that if the COPY is actually two operations, the graphstore might be left in a state after :g1 is dropped, but without the insert being performed (if the INSERT WHERE does fail for some reason). The actual test results for copy/manifest#copy05, however, imply that the expected state of the graphstore is with :g1 still in place with its original content (that is, without the DROP having been performed, or the normal behavior of the INSERT leaving :g1 empty).

In this specific case, a processor could check ahead of time to see if :g4 exists before the DROP is performed, but I think it's necessary to nail down the more general question of whether these shortcut syntaxes are meant to act as a single operation (in which case I'm going to have problems with the normative language on operations being atomic), or whether they act as multiple operations (in which case some of these new tests aren't portable, and need mf:requires assertions at the very least).

Thoughts?

thanks,
.greg

Received on Tuesday, 24 January 2012 16:40:26 UTC