"3.7 Replacing Blank Nodes with IRIs" very misleading

[franconi]

Section 3.7 Replacing Blank Nodes with IRIs states:
systems MAY systematically replace some or all of the blank nodes in an RDF graph with IRIs. Systems wishing to do this SHOULD mint a new, globally unique IRI (a Skolem IRI) for each blank node so replaced.
and it goes on making a very misleading statement:
This transformation does not appreciably change the meaning of an RDF graph, provided that the Skolem IRIs do not occur anywhere else.
In general this is not true, and its application has to be understood deeply. This statement has already created damages in the definition of SPARQL OWL entailment regime.
As an example, consider the following valid entailment:
:a :b _:x. ⊨ :a :b _:y.
By naïvely applying the above skolemisation process, we get that:
:a :b :sk-x. ⊭ :a :b :sk-y.
I don't see how the applicability conditions of skolemisation could be easily explained without using heavy logic machinery.
I also don't see why there should be such a Section in RDF-Concepts.
I propose to just kill Section 3.7.

[doerthe]

I sympathize with that suggestion, we could alternatively go for a statement on equisatisfiability. something like:

"With this transformation we get an equisatisfiable graph to the original one, provided that the Skolem IRIs do not occur anywhere else."

Not the perfect wording and the question remains whether we should go there because we most likely need to add more explanation (and proofs), if we do...

[afs]

I also don't see why there should be such a Section in RDF-Concepts.

Me neither.

I don't understand why this section is normative. The SHOULD is gated by the MAY (=optional) and I couldn't find any tests for skolem IRIs in https://github.com/w3c/rdf-tests/rdf. The section is more like advice.

Has it ever been seen in data published on the web (not within a closed application of RDF, where data producer and consumer are controlled)?

I propose to just kill Section 3.7.

It could at least be relegated to a non-normative appendix, or made into a WG Note.

I would not disagree with removal.

[doerthe]

Note that the section goes together with section 3.8 from RDF semantics (https://www.w3.org/TR/rdf11-mt/#skolemization-informative). Maybe we can change the wording in RDF concepts (especially removing what is wrong) and add a link to the semantics where (non-)entailments are explained.

[afs]

It is all a bit odd. That non-normative section defines skolemization. RDF Concepts does not refer to RDF Semantics.

Maybe move the Concepts text to RDF Semantics (and both as an appendix?) so it can be read as one unit.

[franconi]

I don't think that the issue is whether this is normative or non-normative, nor whether it is in this document or somewhere else.
The point is that it is just wrong, and that it is not useful.
And, in order to make it right and not misleading, a lot of logic-based explanations need to be done - which probably is not worthwhile.

[doerthe]

I could be wrong, but I am afraid that people are already using skolem iris and the spec does not only make these confusing claims, it also gives some guidance how the concret iris should be constructed. Unless this is stated somewhere else, I think we can't simply remove them. This is a bigger change to the existing standard.

What we can do is make the link to the semantics section and remove everything which is obviously wrong. We can extend the semantics section to at least point out that things are complicated here...

[pfps]

As an example, consider the following valid entailment: :a :b _:x. ⊨ :a :b _:y. By naïvely applying the above skolemisation process, we get that: :a :b :sk-x. ⊭ :a :b :sk-y.

Except that the transformation is supposed to be only on for RDF graphs that are premises. I suppose that this should be stated more clearly instead of just being implicit because the section is part of Concepts.

[afs]

I am afraid that people are already using skolem iris

I have not seen it on the web.

Disclosure: Jena uses <_:internalGlobalID> which is intentionally an illegal URI (and hence strictly "not RDF" by design); it reverses the encoding on parsing so it is a stronger contract that RDF Concepts. The stronger contract is needed to have a bnode across OS processes or across machines.

What we can do is make the link to the semantics section

If semantics is the only use, then leaving it in RDF Concepts serves no value and can only confuse the reader.