Re: entailments and the unstar mapping

On 20 Mar 2023, at 13:40, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:

What it boils down to is that the exact 'unstar:' namespace does not really matter, as it is an "implementation detail"...

Another way would have been to start by saying;
  "find an IRI prefix that is not never used in the graph(s) under consideration and called that unstar:"

I agree.

Roughly speaking, an RDF-star triple T is RDF-star entailed by RDF-star graph G if and only if L(G) RDF-1.1 simply entails L(T).

I assume that 'L' means the same as 'unstar'? In that case, yes, I agree.

Yes.

Note also that, while we agree on this, this does *not* mean that G and unstar(G)/L(G) have the same entailments... (I don't mean to be petty here)

Right, it holds strictly only in the sense I wrote previously.

Notice that the game changes already for extensions such just adding owl:sameas, where the above is not true anymore.
I don't see why. Could you develop?

Observe the following (with semantic predication):
<<:a :b :c>> owl:sameas <<:d :e :f>> .
entails (and it is entailed by)
:a owl:sameas :d .
:b owl:sameas :e .
:c owl:sameas :f .
but this can not be captured with the L/unstar transformation under RDF 1.1 simple entailment augmented with owl:sameas.

cheers
—e.