W3C home > Mailing lists > Public > public-sparql-12@w3.org > January 2020

Re: Conditional Requests to resolve semaphore and confidentiality concerns

From: james anderson <james@dydra.com>
Date: Thu, 16 Jan 2020 18:20:55 +0000
Message-ID: <0102016faf963809-09fa7f6e-91c3-4ffd-839c-81a43c7404fb-000000@eu-west-1.amazonses.com>
To: "SPARQL 1.2 Community Group" <public-sparql-12@w3.org>
good evening, 
> On 2020-01-16, at 13:31:28, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
> 
> Hi all,
> 
> I'm working on the Solid project[1], where we use Semantic Web technologies 
> intensively. For now, SPARQL is only used on the server side to update 
> documents, and not using the SPARQL Protocol, a SPARQL 1.1 Update query is 
> passed as the body of a PATCH request[2]. 
> 
> We have an open issue on the level of SPARQL 1.1 Update support Solid should 
> require[3], and I have been working on two points where there are some 
> tensions. I have a rather involved proposal to address them both in a 
> backwards compatible way, that I want to air with you. The TL;DR is: We 
> should support issue 63 [4] and introduce a conditional request header into 
> HTTP.
> 
> These are the issues:
> 
> 1) A semaphore mechanism for updates.
> 
> [under certain circumstances], the Solid implementation 
> would return a 409 Conflict to the second client. ...
> 
> 2) A mechanism to communicate status from write queries safely.
> 
> […]
> 
> What do you all think?

the suggestion here does not convince any more than #60 did then. 
as per the comment from 19.june, it remains, that the application which is not prepared to model the meta-state and attempts to divine it from the incidental store state will have no way to guarantee integrity.
the overhead incurred when each delete acts also as a probe is not justified.
Received on Thursday, 16 January 2020 18:21:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:46 UTC