Re: [RDF-CONCEPTS] Skolemization

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)

	Andy


>
>
>
>>
>> does that make more sense now?
>>
>> David
>>
>

Received on Monday, 17 June 2013 08:37:17 UTC