> > > > But an implementation is also free to reject a second request, per the > > specification? > > > > So for SPARQL 1.1 a write strategy portable across implementations > > should be sequential, i.e. one request has to complete before the next > > one is executed? > > Strange question - why do you ask?
I ask because we have a client implementation and we want to have the write strategy as general as possible, and not triplestore-dependent. > FWIW: By the spec, a server can reject any request just because it feels > like it. > > Fuseki doesn't; it does not return 202 either. But there must be a limit to how many write requests Fuseki can queue? > Are you saying that some servers reject (true) concurrent writes? Yes, Dydra does that. James can probably expand on this. Data imports from our system can produce large and overlapping GSP write requests, but we cannot send them simultaneously if we want them to succeed.
