W3C home > Mailing lists > Public > public-rdf-comments@w3.org > June 2013

Re: [RDF-CONCEPTS] Skolemization

From: Andy Seaborne <andy@apache.org>
Date: Mon, 17 Jun 2013 09:36:46 +0100
Message-ID: <51BECA9E.7080605@apache.org>
To: public-rdf-comments@w3.org
On 17/06/13 07:54, Ivan Herman wrote:
> David Booth wrote:
>> On 06/16/2013 06:22 AM, Ivan Herman wrote:
>>> I have not looked at the text right now (I am on a mobile), and that may be good
>>> at this moment, because it shows what I remember the intention was...
>>> I guess the question of David could/should be boiled down to: is the
>>> Skolemization part normative or not? I think we never meant that to be normative
>>> in the group; if it says so in the document, that is a mistake (Pat already
>>> alluded to that). If it is non normative, then the usage of an RFC MUST would
>>> become fairly meaningless... Is there any reason we would make it normative?
>>> This request never came up in the group before; the whole skolemization was
>>> presented as a good practice to follow if one wants to get rid of bnodes when
>>> exchanging graphs.
>>> (Systems may skolemize for any other reason, eg, for internal purposes or
>>> exchanging data with other instantiation of the same software only, and they may
>>> decide to use some sort of a UUID based URI which would be just as fine. If we
>>> set a 'must' for the genid way, then a UUID based skolemization might be
>>> considered as illegal:-(
>> aha!  I think I see where the confusion lies, and I apologize for not noticing
>> this sooner.  :(
>> I believe we are talking about two different kinds of skolemization. the first
>> is what I will call *unconstrained* skolemization, and this is the process of
>> properly substituting arbitrary new IRIs for bnodes.  for this, any kind of IRI
>> will do.  the second I will call *round-trippable* skolemization, and this
>> *requires* that the IRIs be minted using the "genid" well-known suffix, so that
>> they can be Predictably recognized by other parties.
>> the definition of *unconstrained* skolemization does not need to be normative,
>> because other parties will not be depending on recognizing its result.  but the
>> definition of *round-trippable* skolemization *does* need to be normative, so
>> that other parties acting independently can Predictably recognize the
>> *round-trippable* skolem IRIs and turn them back into bnodes if desired.
> Well... even that can be questioned, just to play it hard ball:-).
> Round-trippable skolemization without prior agreement is where the current
> skolem approach is handy. I mean, if you and I exchange data and we agree to use
> a particular skolem scheme, than we achieve what we want...
> I am a little bit afraid we get into too much details here. If the intention of
> skolemizing is to broadcast the data to the wide world for round tripping, then
> the skolemization in the document is the obvious answer, and anybody in their
> sane mind would go for that. I am not sure this would require the additional
> step of making it normative with a MUST (but that is the WG to decide, I am
> fairly neutral about it)
> ivan

There seem to be 3 kinds of skolemization:

1/ replacement (unconstrained; one-way)

2/ round-trippable (the generating system can recover a bNode if the URI 
comes back; this was one of the original motivations)

3/ globalization (giving a recognizable identify to the bnode outside 
it's original context/data; the bnode is now transferrable to other 
systems; other systems can reverse the process)


>> does that make more sense now?
>> David
Received on Monday, 17 June 2013 08:37:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:57 UTC