Re: entailments and the unstar mapping

Understood, but users doing something “in the hope that it has some semantics” should not be much of a design requirement for us. ;-)

Ora


From: Pierre-Antoine Champin <pierre-antoine@w3.org>
Date: Thursday, March 23, 2023 at 11:21 AM
To: "Lassila, Ora" <ora@amazon.com>, Franconi Enrico <franconi@inf.unibz.it>
Cc: RDF-star WG <public-rdf-star-wg@w3.org>
Subject: RE: [EXTERNAL]entailments and the unstar mapping



On 23/03/2023 13:20, Lassila, Ora wrote:
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.
Yes, that's what I meant. Sorry for the confusion.


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”.

As a matter of fact, the mapping is designed in such a way that nothing will break, because all unstar:* IRIs used in the RDF-star graph will be "escaped" (by appending an underscore to them) to avoid any interference.

The risk is the opposite: people using the unstar: vocabulary in the hope that it has some semantics at the RDF-star level, which it does not (and should not, IMO).

So in fact, it does not matter for users what the exact IRIs of the unstar: vocabulary are -- they only have a special semantics under the hood. That's why another way of formalizing this is to say "use any set of IRIs that is not present in the original graph".
I would prefer the language “it is an error…”

Saying "you can use any IRI... except those ones" does not seem to be "the RDF way" either...

  pa
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><mailto:pierre-antoine@w3.org>
Date: Thursday, March 23, 2023 at 7:23 AM
To: Franconi Enrico <franconi@inf.unibz.it><mailto:franconi@inf.unibz.it>
Cc: RDF-star WG <public-rdf-star-wg@w3.org><mailto:public-rdf-star-wg@w3.org>
Subject: RE: [EXTERNAL]entailments and the unstar mapping
Resent-From: <public-rdf-star-wg@w3.org><mailto: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.