W3C home > Mailing lists > Public > semantic-web@w3.org > September 2014

Re: Turtle Patch simplification (N3 Patch?)

From: <henry.story@bblfish.net>
Date: Sun, 21 Sep 2014 13:51:30 +0200
Message-Id: <5AD68689-4501-4240-9705-C91726D73900@bblfish.net>
To: public-ldp-comments@w3.org, public-ldp <public-ldp@w3.org>, Semantic Web <semantic-web@w3.org>, Linked Data Platform WG <public-ldp-wg@w3.org>
A bit of context: this e-mail is part of the discussion on LD-Patch 
formats for LDP which is in last call. Alexandre Bertails has a nice
summary of the options that were considered


"N3Patch" which is an idea I am just exploring here as a 
further option may be another possible way to go. 

Some further thoughts I had since yesterday:

1. Deletion can be expressed with a relation to an empty graph

  { _:bnx1 foaf:knows _:bnx2 } patch:replaceWith {}

2. Addition can be expressed with a relation from an empty graph

  {} patch:replaceWith { _:bnx1 foaf:knows _:bnx3 }

3. One can add metadata to the patch quite easily. Perhaps like this:

  <> rdfs:comment "This patch request followed from Asterix and Obelix becoming 
       friends again". 

  { _:bnx1 foaf:knows _:bnx2 } patch:replaceWith { _:bnx1 foaf:knows _:bnx3 }

  I suppose here <> refers to the state of the transition between the two states
  of the resources....

The advantages here is that there is no graph that could not be patched with 
this method it seems.

On 20 Sep 2014, at 12:57, 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.
> 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 - 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
> 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/

Social Web Architect
Received on Sunday, 21 September 2014 11:52:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:39 UTC