Re: deterministic naming of blank nodes

> On May 20, 2015, at 11:16 AM, henry.story@bblfish.net wrote:
> 
> 
>> On 13 May 2015, at 08:14, ahogan@dcc.uchile.cl wrote:
>> 
>> 
>> Sorry for resurrecting old threads but this discussion sort of prompted me
>> to work on the topic of "deterministic naming of blank nodes" and I
>> thought that it might be time (six months or so later) to report back on
>> some findings.
>> 
>> The result is the paper here:
>> 
>> 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]
> 
> Great news!
> 
> In your article you two main use cases for this algorithm
> 
> [[
> 1. checking the isomorphism of RDF graphs or identifying groups of isomorphic RDF graphs from a large collection without requiring pair-wise isomorphism checks; 
> 2. Skolemising RDF graphs such that the output graphs are equal if and only if the input graphs are isomorphic
> ]]
> 
> Would this not also allow the creation of a very simple UPDATE language to allow a client to make a change to a graph on the server?  One could imagine a SPARQL Update with a new mime type that would allow the client to use this in a PATCH request (  as sepecified in the LDP specification ). One could take a simple subset of SPARQL PATCH and give it a variant mime type for the server to indicate its ability to support such requests.
> 
> It would be nice if one could also use the calculation to create stable representations of rdf on disc - so that diffs between two versions can easily be found in say a git diff command. ( Even nicer if one could write it out in a human readable for such as turtle, but I don't expect that much )

This is similar to the Diff use case that David Booth brought up. Given appropriate Skolem IDs used in naming BNodes, there are many cases where two datasets can be compared to form a diff set, but there are a large number that can’t as well. 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.

Gregg

> Henry
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
>

Received on Wednesday, 20 May 2015 19:45:00 UTC