Re: C14N use case: version control

On 29/06/11 01:22, Pat Hayes wrote:
>
> 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?

If a parser processes skolemization URIs as if they were bNode labels in 
whatever the syntax is the document is in, then it's possible to 
reproduce a graph which is bNode-isomorphic to the original.

Now that's relying on being able to spot skolemization URIs, but we went 
and made them .well-known.

> 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....)

If the skolem URI is passed back to the originator, the 
creator/discoverer of the bNode in the first place, the skolemization 
URI could contain enough information to reconstruct the original data 
object representing the bnode.

It's a mapping between concrete syntax spaces - assuming the special 
nature of skolem URIs, the spaces are isomorphic and the URIs are 
.well-known.  Absent owl:sameAs, or using that URI pattern for an 
NIR/IR/Literal.

>
>> 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 08:32:37 UTC