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

On 09/20/2013 05:30 AM, Svensson, Lars wrote:
>>> 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

Yeah, exactly what you two are saying.   The server needs to communicate 
to clients what bits of RDF it understands to look for in PATCHes (and 
also in POSTs, I think, would be very useful, for things beyond LDP, 
too) to guide its actions.

This knowledge can be RDF metadata, which can be embedded in the 
content, or conveyed using HTTP headers. Using the Link header as Lars 
suggests is good, since it avoids any need for additional work at the 
IETF (as fun as that might be).

I imagine a robot car which accepts instructions via POST that look like 
this:

    PREFIX : <http://robotcar.example.org/ns/ctrl#>
    [ a :SetSpeed; :speed 41.2 ]

and

    PREFIX : <http://robotcar.example.org/ns/ctrl#>
    [a :SetSteeringAngle; :angle 120 ]

The server would need to tell the client that it understands stuff like 
this.   As Martin suggests, it could say it understands the 
'http://robotcar.example.org/ns/ctrl#' vocab.   When I was thinking 
about this before, I suggested it name the specific classes of requests 
it implements (in this case 
'http://robotcar.example.org/ns/ctrl#SetSpeed' and 
'http://robotcar.example.org/ns/ctrl#SetSteeringAngle').

Having attended the RDF Validation Workshop last week, I now see the 
best option, long term, could be to use the eventual output of that 
work, which will be some way to express certain RDF graph patterns.   It 
would be really nice to be able to pass one URI, which via dereference 
explains exactly which classess and properties the server will 
understand in a request.

So, for POST the server might include this header:

    Link: http://robotcar.example.org/ns/basic-commands 
rel="http://www.w3.org/ns/ldp#acceptPattern"

... where I'm proposing ldp:acceptPattern is an RDF predicate linking a 
resource to the pattern of RDF graphs (as per RDF Validation) that will 
be accepted.    Coming back to PATCH, I imagine it might also include 
this Link header:

    Link: http://www.w3.org/ns/patch#basic 
rel="http://www.w3.org/ns/ldp#acceptPatchPattern"

... where I'm imagining ldp:acceptPatchPattern is an RDF predicate 
linking a resource to the pattern of RDF graphs that will be accepted as 
patch requests, and ...#basic is one such pattern.

Anyway -- I raised this with Erik because I was wondering if, from an 
IETF/ReST perspective, there was any better/existing solution.

         -- Sandro

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