Re: entailments and the unstar mapping

On 20/03/2023 23:21, Franconi Enrico wrote:
>
>> 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.
Indeed. The intention of the CG semantics was to focus on syntactic 
predication for quoted triples,
and rely on TEPs for emulating (so to speak) semantic predication.

So the above inferences are, by design, not supported by the CG semantics.

>
> cheers
> —e.
>