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

Its commonplace for SQL apps to insert blank rows (without `id`) to master 
fact tables and use the last_insert_id() from the server (eg. usually 
uint64 primary auto-increment) as a foreign key in followup metadata.

Similarly, materializing IDs for blanks RDF nodes seems fine, but I do not 
see the advantages of /.well-known/ prefixing. Doesn't this common URI 
space create a potential for ID collision? Is that a bug or feature? :)

Some URI endpoints want to generate <sha1:x> for the blank data coming in. 
For the SQL backed graph example, perhaps simply <#1>, <#2>, with paging, 
or even separate graphs per record would be fine.

Is there a recipe I missed for using genids without the ID management 
overhead? Are you supposed to append the full resource URL to the genid 
space?

--
Joe Presbrey

On Fri, 31 Jan 2014, Sandro Hawke 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
>
>

Received on Wednesday, 5 February 2014 01:38:13 UTC