Re: C14N use case: version control

On Jun 28, 2011, at 9:48 AM, Gavin Carothers wrote:

> On Tue, Jun 28, 2011 at 6:55 AM, Andy Seaborne
> <andy.seaborne@epimorphics.com> wrote:
>> 
>> 
>> On 27/06/11 19:55, Jeremy Carroll wrote:
>>> 
>>> This is the use case that TopQuadrant has internally that prompted
>>> discussion between me and Gavin leading to this thread on this mailing
>>> list.
>>> 
>>> A significant portion of our product source is in RDF.
>>> We are migrating our version control system to GIT to reduce cost of
>>> merging
>>> This will not work for RDF in the form that we currently store it,
>>> because simple changes result in completely different documents
>>> We are now working on a version of my earlier paper with additional
>>> steps to insure reasonable stability of blank node IDs.
>>> 
>>> (In the terms of the paper the bnode ids will be based on a hashcode
>>> generated from the first distinctive triple for that bnode).
>> 
>> I'm curious - why not store skolemized data?  The skolemization URI could
>> record sufficient information related to when the bNode id was first
>> created.  It's then fully reversible in syntax terms (with a little parser
>> processing "deskolemization") to make bNodes reconstructable.
> 
> Is skolemization fully transitive? Once the parser has created the
> blank node will another seralizer produce the same skolemized blank
> node?

That question is meaningless. What do you mean by 'the same ... blank node'? And what do you mean by a 'skolemized blank node', for that matter? (Once skolemized, it is no longer a blank node, right? Which is the whole point....)

> I don't think the current proposals do that. How would that
> happen?

WIth the only interpretation that I can give your question, it could never happen. Unless maybe you "deskolemized" by keeping the original graph in a cache somewhere and delivering it unchanged when presented with the skolemized version.

> Would all implementations keep track of the skolem id after
> reconstituting the blank node? In which case aren't we just turning
> blank nodes into syntactic sugar for a skolem iri? (No objection to
> that btw, but it's a bit odd)
> 
>> 
>> For me, this is the point of skolemization - finding a bNode again need not
>> be just across the web; it can also be temporally across serialized data.
> 
> I agree, this FELT like the point of skolemization, but I'm not sure
> that skolemization actually provides this. I'm just not sure how the
> skolemization process is supposed to provide a stable blank node label
> without either solving graph isomorphism or implementing something
> very much like the c14n proposal here. In other words I do think that
> skolemization could be used rather then "modifying the graph" ...
> mostly since skolemization modifies the graph.
> 
> --Gavin
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 29 June 2011 00:23:31 UTC