Re: 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>
> *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.
>