Re: using con-neg for a genid view, maybe solving the PATCH dilemma

Hi Sandro,

very elegant indeed.

The only drawback that I can see is that clients willing to use TurtlePatch
will either have to

- perform an additional GET with Accept:text/turtlepatch just before they
do the PATCH, or
- systematically require text/turtlepatch when they GET any resource
representation.

I'm not sure about the impact of the second option...



On Fri, Jan 31, 2014 at 6:15 PM, Sandro Hawke <sandro@w3.org> wrote:

> Yesterday, Cody got me thinking about PATCH again and I had an idea
> which I think threads the ldp-patch needle nicely.
>
> Cody's LDP implementation is using TurtlePatch [1], which you'll recall
> is a tiny subset of SPARQL 1.1 Update which is easy to parse and execute
> in linear time.   It has no variables and cannot operate on blank
> nodes.   So, it's great, as long as you have no blank nodes.  To me, in
> recent years, that made it basically useless. But now I see how to make
> it okay.
>
> My idea was that the server could provide a Skolemized (genid) view of
> the data, suitable for easy patching with TurtlePatch, but not affecting
> how everyone else interacts with the data.  Specifically, I'm thinking
> that if the client does a GET with "Accept: application/turtlepatch"
> then it gets a patch from the empty graph to the current graph, with all
> the blank nodes Skolemized in some way the server will accept for future
> PATCH operations.    You can also think about what it gets as
> slightly-restricted Turtle with three extra boilerplate lines.
>
> For example:
>
> GET http://example.org/alice
> Accept: text/turtle
>
>      PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>      PREFIX : <http://example.org/>
>      :me foaf:knows [ foaf:name "Bob" ].
>
>
> GET http://example.org/alice
> Accept: text/turtlepatch
>
>      PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>      PREFIX : <http://example.org/>
>      PREFIX genid: <http://example.org/.well-known/genid/d7432/>
>      INSERT DATA {
>      :me foaf:knows genid:517.
>      genid:517 foaf:name "Bob".
>      }
>
> The difference here is that text/turtlepatch has the INSERT DATA
> boilerplate and is Skolemized.   (It's also restricted to not have any
> newlines in string literals, but use \n instead.)  The idea is that
> clients can ask for this Skolemized version, and then patch it easily
> and efficiently with TurtlePatch.   If they're expecting to be patching,
> I imagine they'll generally fetch with turtlepatch instead of turtle.
>
> My sense is this is pretty easy to implement assuming the server (1) has
> some kind of access to .well-known/genid URI space on its host and (2)
> has stable internal identifiers for blank nodes which it can expose or
> efficiently map to/from something it can expose.  (There's probably a
> workaround if (1) isn't true.)
>
> What do you think?
>
> There are other ways one could ask for a skolemized view, of course.
> One could have parallel resources, and have Link headers between the
> two.   In practice, it might turn into adding a ?genid=true to the URLs
> or something.    Or one could make a variation of turtle, with
> media-type text/genid-turtle, or something like that.    But it seems to
> me like a fairly elegant hack to use TurtlePatch for this, since the
> time in your coding you need these two things is the same.  (I note that
> SPARQL's INSERT DATA syntax does allow blank nodes, as a way to create
> fresh blank nodes.  I suggest they not be used when one is using
> text/turtlepatch like this, as an RDF serialization syntax.)
>
>       -- Sandro
>
> [1] https://www.w3.org/2001/sw/wiki/TurtlePatch
>
>
>