Re: [RDF-CONCEPTS] Skolemization

On 17 June 2013 18:36, Andy Seaborne <andy@apache.org> wrote:

> 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)
>
>
There may also be a fourth that is subtly different to 1, in that it is not
a blind one-way process. If the producer and consumer must cooperate to
make an extension of the RDF model work cleanly, and the producer does not
necessarily need to recognise the blank node if it comes back, other than
to recognise that it is a skolemized URI that needs replacement, then the
replacement is not completely unconstrained:

4/ RDF Extensions : (enabling extended models, wrt bnodes, to interact
transparently over RDF) The global meaning may not be important, and they
may not need the ability to recognise the specific bNode if the URI comes
back. The skolemized URI only needs to be recognised by someone who
understands the extended model to replace it with an arbitrary blank node
again (using the same mapping for the same skolem URI for the current
document), without necessarily needing to replace all skolemized blank
nodes, as the others may legitimately have been created as type 2 or type 3
skolemized URIs that still need to be transparently passed through to make
them work at a different level.

In this case the skolemized URI need to be anything that would not be used
as a URI in that document, including skolemized URIs created by another
user in the pipeline. The uniqueness can be ensured in the context of the
document by its lexical structure.

In general such systems will only work with a limited number of users due
to their complexity, however, as JSON-LD is designed to be able to limit
physical documents to match specific APIs there may end up being large
communities of RDF users who have the same issues with a particular
providers JSON-LD documents so it may be useful for those scenarios.

It may still be simpler for JSON-LD-to-RDF mappers to switch to rejecting
unmapped properties in the JSON-LD processing algorithm rather than
attempting partial compatibility for a use case that was not foreseen in
the RDF model. RDF users will never see any value in a blank node
predicate, as they would practically need to have a mapping to a URI to
further interact with the property in a meaningful way, and in that case
the original provider should have been able to map it themselves.

Peter