Re: Turtle Patch simplification (N3 Patch?)

Hi Henry,

On Sat, Sep 20, 2014 at 12:57 PM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

> Turtle Patch [1] makes it obvious that being able to name the bnode
> URIs in a patch request makes patching exceedingly easy to
> implement as well as very easy to create patches. All that is needed for
> a client implementation is to know what triples it needs to remove:
> there is no need to find a pattern that would identify those triples
> among all others. The main problem with Turtle Patch is that it
> requires one to then make a new HTTP request with genid blank nodes,
> to get the patchable format of the resource, or to always request them
> and then sadly turn all bnodes de facto into URIs.
>

Agreed, also I'm not sure I'm coming to the same conclusions as you do
below...

>
> Where there is usually a valid concern about naming bnodes - the
> point of bnodes is that they the server publishing them should not have to
> maintain references to them add eternam


Who says I should maintain them *ad eternam*??
In my understanding, skolemization does not require the genid URIs to be
the same across all successives states (versions) of a given resource. The
only have to persist as long as the resource does not change, so that one
can safely patch it?


> - in the case of a PATCH
> the action is directly on the graph in question, and so there is in this
> case no problem of cross reference with other resources.
>

> Given this I think one should be able to have a simpler version of Turtle
> patch without the need for genids, that keep the bnodes local to the
> resource and that also don't require the extra request to be made to the
> server ( the one that is required to GET the graphs with the genids using
> the "Prefer: return=representation blank-nodes=use-genid" header ).
>
> It could simply be decided that a resource that advertises the given
> Patch Format - lets call it N3-Patch - understands there to be an automatic
> mapping from the order of bnodes in their representation to a set
> of explicit bnodes such as _:bn1 to _:bnN . One could then have something
> like
> the following document at /asterix
>

Well, in my opinion, we are back to problem #1:
you ask the server to maintain an *order*, while the underlying data model
(RDF abstract syntax) has no such notion.
So you still put an extra burden on the server.

Granted, it is not a huge deal, and is probably a good way to keep the
extra information that allows you to skolemize bnodes, but this is still
something that you get out of the box for standard triple stores.

  pa


> GET /asterix HTTP/1.1
>
>
> HTTP/1.1 200 Ok
> E-Tag: "slab v2"
>
> [] foaf:name "Asterix".
>    foaf:knows [ foaf:name "Julius Caesar";
>                 foaf:homePage <http://palace.rome/> ].
>
> [] foaf:name "Obelix" .
>
> And patch it with the following PATCH Request
>
> PATCH /asterix HTTP/1.1
> Content-Type: text/n3
> If-Match: "slab v2"
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/>
>
> { _:bnx1 foaf:knows _:bnx2 } patch:replaceWith { _:bnx1 foaf:knows _:bnx3 }
>
> Which would result in a following request
>
> GET /asterix HTTP/1.1
> Accept: text/turtle
>
> HTTP/1.1 200 Ok
> Content-Type: text/turtle
>
> [] foaf:name "Asterix".
>    foaf:knows [ foaf:name "Obelix" ].
>
> [] foaf:name "Julius Caesar";
>    foaf:homePage <http://palace.rome/>
>
>
> Henry
>
>
> [1] http://www.w3.org/2001/sw/wiki/TurtlePatch
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>