Re: entailments and the unstar mapping

I assume by “IRI prefix” you did not mean a namespace prefix used with qualified names (because those are not part of the RDF abstract syntax or metamodel; rather, they are a serialization syntax vehicle we borrowed from XML originally). I assume you meant something like a namespace IRI instead.

I don’t like the idea of finding an unused one. That is not the “RDF way”, and also I do not know what the implementation ramifications of an approach like that would be. Rather, we should explicitly define a new namespace IRI (something close to the current RDF namespace IRI, perhaps), and use “unstar:” as its qualified name prefix in documentation and examples. If someone wants to manually create data that uses “unstar:” predicates contrary to how we define their usage would have to accept that “all bets are off”. I would prefer the language “it is an error…” in the documentation (used the same way as CLtL2 used it [1]), signaling that it may cause undefined/unexpected behavior.

Ora

[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node11.html



From: Pierre-Antoine Champin <pierre-antoine@w3.org>
Date: Thursday, March 23, 2023 at 7:23 AM
To: Franconi Enrico <franconi@inf.unibz.it>
Cc: RDF-star WG <public-rdf-star-wg@w3.org>
Subject: RE: [EXTERNAL]entailments and the unstar mapping
Resent-From: <public-rdf-star-wg@w3.org>
Resent-Date: Thu, 23 Mar 2023 11:23:10 +0000



On 20/03/2023 23:21, Franconi Enrico wrote:

On 20 Mar 2023, at 13:40, Pierre-Antoine Champin <pierre-antoine@w3.org><mailto: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.