Re: deterministic naming of blank nodes

On 05/20/2015 03:54 PM, henry.story@bblfish.net wrote:
>
>> On 20 May 2015, at 21:44, Gregg Kellogg <gregg@greggkellogg.net>
>> wrote:
[ . . . ]
>>>> Aidan Hogan. "Skolemising Blank Nodes while Preserving
>>>> Isomorphism". In WWW, Florence, Italy, May 18–22, 2015 (to
>>>> appear). Available from:
>>>> http://aidanhogan.com/docs/skolems_blank_nodes_www.pdf [snip]
[ . . . ]
 >> Any triples added
>> referencing a BNode will cause the hash for that node to change.
>> Also, new triples could create automorphisms which could affect the
>> Skolem IDs generated for distinct BNodes having identical hashes.
>> But, these represent corner cases, and a suitably grounded graph
>> should be able to use something like this for doing patches,
>> providing that updates do not reference BNodes, or do so only
>> internally within the update, and that those BNodes not overlap (in
>> subtle ways) with any existing BNodes in the graph to be updated.
>
> Mhh. So that would restrict the PATCH to only conditional PATCH for
> the same etag.

I would think one would always want to use conditional PATCH for the 
same etag anyway, because it would be unsafe to do otherwise:
http://tools.ietf.org/html/rfc5789
[[
    A PATCH request can be issued in such a way as to be idempotent,
    which also helps prevent bad outcomes from collisions between two
    PATCH requests on the same resource in a similar time frame.
    Collisions from multiple PATCH requests may be more dangerous than
    PUT collisions because some patch formats need to operate from a
    known base-point or else they will corrupt the resource.  Clients
    using this kind of patch application SHOULD use a conditional request
    such that the request will fail if the resource has been updated
    since the client last accessed the resource.  For example, the client
    can use a strong ETag [RFC2616] in an If-Match header on the PATCH
    request.
]]

David Booth

Received on Wednesday, 20 May 2015 21:14:23 UTC