Re: patch con-neg, was Re: multiple changes to resources

> Imagine I have five styles of patches I want to do. ...
> Since I'm working with RDF all around, I find it 
> very convenient to express my patches in RDF, so I do that.

> Now, what media type(s) do I use for these patches?   I might want to 
> serialize my patches in Turtle, or Trig, or JSON-LD, or RDF/XML, or 
> N-Quad, or N-Triples.    Each of those has their own media type. Do I 
> need to make a new media type for using those with each kind of patch, 
> above?  That's 30 new media types, so far.

I've seen this problem a few times - the problem of specifying "media 
type" versus specifying what is it that's being expressed by that media 
type. While I've seen a few solutions, I personally haven't been very 
impressed by any of them.

How about defining an HTTP header similar to "Content-Type" and "Accept", 
but which doesn't specify the format that the body is represented in, but 
instead specifies what that format is being used to express (e.g. in RDF, 
the vocabulary/ies in use).

e.g. a resource could include in its response headers:
Accept-Patch: application/rdf+xml, application/x-turtle
Accept-Patch-Vocab: ldp:simplePatch, ldp:variablePatch, ldp:listPatch

and then a patch to that URL could specify:
Content-Type: application/rdf+xml
Vocab: ldp:simplePatch
(Although in this case this might be redundant, as it should be obvious in 
the RDF by the terms in use.)


This could also work for versioning vocabularies when retrieving resource 
representations.

e.g. In a GET request, the client sends:
Accept: application/rdf+xml, application/x-turtle
Accept-Vocab: ldp:LDP;version=1.0

And then the server responds with a request using LDP v1, including the 
headers:
Content-Type: application/x-turtle
Vocab: ldp:LDP;version=1.0
Vary: Accept, Accept-Vocab

Then when terms in one namespace/spec get superceded by some equivalents 
in another, this could be used for clients that only understand one of 
those two alternatives to retrieve the resource in a representation that 
they understand.
(However, I'm not sure of when these would be best sent (e.g. always, or 
only when data is not understood), and what is the best behaviour when 
they are not specified.)

Of course, the way that the vocabularies are identified could be in any 
number of ways - prefixed names might not be suitable in HTTP headers. But 
the main idea is in the meaning of the headers. ("Vocab" might not be a 
suitable term for non-RDF media types, while the general 
2nd-level-of-content-negotiation idea may well be, so there might be a 
better name for the headers.)

Any thoughts?
Is there anything that can do things like this already?

Martin Pain





From:   Sandro Hawke <sandro@w3.org>
To:     Erik Wilde <dret@berkeley.edu>, LDP WG <public-ldp@w3.org>, 
Date:   20/09/2013 05:31
Subject:        patch con-neg, was Re: multiple changes to resources



On 09/19/2013 07:13 PM, Erik Wilde wrote:
> hello sandro.
>
> On 2013-09-19 14:54 , Sandro Hawke wrote:
>> Ideally, I'd like us to be able to handle high concurrency (10+ patches
>> per second to a resource), which I think requires blind patching (aka
>> context diffs).  A little concurrency can be handled by the If-*
>> headers.  If you get an accidental collisions while using them, one of
>> the clients will back off and retry and it'll be fine.   But as the
>> modification rate climbs, backing off becomes problematic. Once the
>> modification rate exceeds the round-trip-time for some clients, those
>> clients become completely unable to modify the resource.   The solution
>> is for clients to construct patches which work even if the resource has
>> changed since they last knew its state (aka blind patching with context
>> diffs). I believe that can be done by having the client communicate to
>> the server which triples (existing and not-yet-existing) it's relying 
on
>> being unmodified.    The If-* headers basically implement optimistic
>> concurrency control [1] at the per-resource granularity.  What I'm
>> proposing is that we go down to per-triple granularity with OCC to
>> enable real-time interaction using LDP.
>
> what you're proposing is (possibly a set of) PATCH document types for 
> RDF, potentially with different patch semantics (and side-effects). 

I think the market would be much better off if we can settle on exactly 
one to Recommend for now, although of course the system should support 
negotiation for others, for use in specialized systems and for the day 
when something way, way better comes along.   But that's already in LDP, 
since it's basically specified by the PATCH RFC.


> that would be a great thing to go for from the architectural point of 
> view. servers could advertise support for patch media types they 
> support, and clients could pick one of the supported ones that they 
> support, and think will work well. JSON and XML have started defining 
> PATCH formats (JSON has one and another one is underway, for XML one 
> is underway), and RDF might want to go that way as well.
>

So, having just said this is already in LDP, I have to say I think using 
media types to specify what kind of patch you want, in an RDF world, is 
problematic.    I didn't object to it being in LDP, because it's already 
set by the PATCH RFC, and so it's kind of late to raise a stink.   But 
since you mentioned this, I'll pass on my complaint.  Maybe you know a 
way to make this work.

Imagine I have five styles of patches I want to do.   Like a plain patch 
(no blank nodes), a patch with variables so it can handle blank nodes, a 
patch with sub-patches which are each atomic, a patch with a bit of 
embedded JavaScript for server-side processing, and ... I dunno, a patch 
which can edit lists.  Since I'm working with RDF all around, I find it 
very convenient to express my patches in RDF, so I do that.

Now, what media type(s) do I use for these patches?   I might want to 
serialize my patches in Turtle, or Trig, or JSON-LD, or RDF/XML, or 
N-Quad, or N-Triples.    Each of those has their own media type. Do I 
need to make a new media type for using those with each kind of patch, 
above?  That's 30 new media types, so far.

       -- Sandro

> cheers,
>
> dret.
>




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU