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

> > 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.

[...]

> 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?

Could it be an option to use the Link header with "profile" (RFC 6906 [1]) to specify this?

Request:
Accept: application/rdf+xml, text/turtle
Link: <http://example.com/LDP-1.0>;rel=profile

Response:
Content-Type: text/turtle
Link: <http://example.com/LDP-1.0>;rel=profile
Vary: Accept, Link

[1] http://www.ietf.org/rfc/rfc6906.txt

Lars

***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de


> -----Ursprüngliche Nachricht-----
> Von: Martin P Pain [mailto:martinpain@uk.ibm.com]
> Gesendet: Freitag, 20. September 2013 11:04
> An: Sandro Hawke
> Cc: Erik Wilde; LDP WG
> Betreff: 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

Received on Friday, 20 September 2013 09:31:21 UTC