Re: Need for hard fail on missing delete triples Re: Updated LD Patch specification

Hi all,


On Wed, Nov 26, 2014 at 7:50 PM, Alexandre Bertails <alexandre@bertails.org>
wrote:

> Hi Tim,
>
> On Wed, Nov 26, 2014 at 1:30 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> >
> > On 2014-11 -24, at 23:07, Alexandre Bertails <alexandre@bertails.org>
> wrote:
> >
> >> Tim,
> >>
> >> On Mon, Nov 24, 2014 at 10:50 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> >>>
> >>> On 2014-11 -24, at 16:07, Alexandre Bertails <alexandre@bertails.org>
> wrote:
> >>>
> >>>> On Mon, Nov 24, 2014 at 4:00 PM, Steve Speicher <sspeiche@gmail.com>
> wrote:
> >>>>> On Mon, Nov 24, 2014 at 3:52 PM, Alexandre Bertails
> >>>>> <alexandre@bertails.org> wrote:
> >>>>>> On Mon, Nov 24, 2014 at 3:42 PM, Steve Speicher <sspeiche@gmail.com>
> wrote:
> >>>>>>> On Mon, Nov 24, 2014 at 2:30 PM, Alexandre Bertails
> >>>>>>> <alexandre@bertails.org> wrote:
> >>>>>>>> On Mon, Nov 24, 2014 at 2:10 PM, Steve Speicher <
> sspeiche@gmail.com> wrote:
> >>>>>>> ...snip...
> >>>>>>>>>
> >>>>>>>>> <#delete-statement> I wonder about this requirement:
> >>>>>>>>> "It fails if one of those triples does not exist in the target
> graph." and later
> >>>>>>>>> "If a Delete attempts to remove a non-existing triple, then a
> HTTP 422
> >>>>>>>>> (Unprocessable Entity) error status code must be returned."
> >>>>>>>>> I wonder why this requirement exists?
> >>>
> >>>
> >>> For example,
> >>>
> >>> 1)  if two users are updating the same application data,
> >>> if they make conflicting changes you may want one of them to fail with
> a beep and the other to succeed.
> >>>
> >>> 2) As another example, if you want to give out a series of identifiers
> one way is to increment
> >>> a triple
> >>>
> >>>        :foo :nextSequence 9.
> >>> to say
> >>>        :foo :nextSequence 10.
> >>>
> >>> so that you have uniquely claimed sequence number 9.
> >>> If someones else tries first, you get a failure.
> >>>
> >>> My current software returns 409 Conflict
> >>> This also suggested in the 2009 note
> >>> http://www.w3.org/DesignIssues/ReadWriteLinkedData.html
> >>
> >> We discussed the option of using ETags for handling this use-case.
> >> This is another way to detect conflict, also resulting with a 409
> >> Conflict.
> >>
> >> Would you be happy with that option?
> >
> > No, I think that we need to leave app designers the option of not using
> eTag.
> >
> > eTag means you have to sync up, and if something is changing frequently
> then you are likely  to be  caught constantly reloaded a resource and never
> being able to edit it.    Imagine a single resource which contains say the
> lines of a etherpad session, where people are interactively editing
> different, or somethings the same line, in  a random way.  You might want
> to design the app so it does optimistic concurrency,  sending in changes in
> a torrent and backing back out at the UI the ones which get a conflict
> error.    Maybe not a great example, but insisting that people use eTag
> rules out this more optimistic concurrency.
>
> I understand this use-case as well. Forcing the use of ETags is not
> always practical.
>
> >
> >
> >>
> >>> Not sure why the spec suggests 422 instead.
> >>> Maybe a good reason.
> >>
> >> Delete-ing a non-existing triple can happen because of conflict, but
> >> more generally it is just an "unprocessable request". Here is the
> >> corresponding text from the relevant RFC  [1]:
> >>
> >> [[
> >>   Unprocessable request:  Can be specified with a 422 (Unprocessable
> >>      Entity) response ([RFC4918], Section 11.2) when the server
> >>      understands the patch document and the syntax of the patch
> >>      document appears to be valid, but the server is incapable of
> >>      processing the request.
> >> ]]
> >>
> >>> I can see others having a different requirement for a "delete if it
> exists" which does fail silently if it doesn't.
> >
> > I think in fact two ldpatch verbs, delete and deleteAny would be simple
> way to solve this problem.
>
> I was expecting this answer :-)
>
> But I don't want to constrain us with this specific solution for now,
> that is: two Delete-s. There are other related questions to discuss to
> make the choice consistent with the other operations. I will come up
> with a list of proposals for the next meeting so that the group can
> see what options are available, with their trade-offs.
>

Here's another idea :

you can ensure that the triple you want to delete exists using Bind :

  Bind ?assert :s / :p [= :o] .
  Delete { :s :p :o } .

Granted, this is somehow hijacking the Bind statement. But on the other
hand, it allows you to assert *just* the relevant triples, and possibly
delete others in a more tolerant way, e.g.:

  Bind ?assert :s1 / :p1 [= :o1] .
  Delete { :s1 :p1 :o1, :o2 ; :p3 :o3 } .

If we want to encourage this kind of use, we could add an Assert that would
look less like a hijacking:

  Assert :s1 / :p1 [= :o1] .
  Delete { :s1 :p1 :o1, :o2 ; :p3 :o3 } .

I imagine that Assert could acccept either a 'subject path' or a whole
graph enclosed in curly brackets, so you could also write:

  Assert { :s1 :p1 :o1, :o2 ; :p3 :o3 } .
  Delete { :s1 :p1 :o1, :o2 ; :p3 :o3 } .

Tim, would these provide a satisfying solution to your use case?
(assuming Alex and Andrei don't think I'm going crazy with this... ;)

  best


> >> If ETags are not an option for you, would you like to make a suggestion?
> >
> >
> > I am happy for etags to to be available for others.
> > I may indeed use it for some apps.
> >
> > Another comment on the spec:  you need to specify how the new etag value
> back from the server.
>
> You mean generally? Or in the response to a PATCH request? I am
> wondering what the spec should say beside what the HTTP PATCH and
> ETags spec say. I was thinking that a non-normative remark would have
> been enough.
>
> Alexandre
>
>
>
> >
> > Tim
> >
> >>
> >> Cheers,
> >>
> >> Alexandre
> >>
> >> [1] http://tools.ietf.org/html/rfc5789
> >>
> >>
> >>>
> >>>
> >>> timbl
> >>>
> >>>
> >>
> >
>
>