W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2011

Re: C14N use case: version control

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Thu, 30 Jun 2011 04:54:12 -0700
Message-ID: <4E0C63E4.4060401@topquadrant.com>
To: public-rdf-wg@w3.org

Andy wrote:
> 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 think this could be made to work, some issues - thinking out loud:

Using Skolem IDs for this use case requires that the triple store has 
support for Skolem IDs (i.e. can present Skolemized nodes as blank, 
while preserving the skolem ID)
Some support for a triple store preserving non-native Skolem IDs
Some support for avoiding collisions in Skolem IDs (my understanding is 
that while the Skolem IDs are likely not to collide this is not guaranteed?)

  A difference, for the version control use case, is that if two users 
make the same change involving adding a blank node, Skolemization will 
have these as definitely incompatible, whereas C14N would almost 
certainly have them as identical (i.e. unless the blank node is 


So, if this were the only use case, I would be inclined to say we have 
two possible, and quite different, solutions and we would need to do 
some evaluation process to work out the pros and cons

Received on Thursday, 30 June 2011 11:54:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:59 UTC