Re: entailments and the unstar mapping

On 20/03/2023 11:49, Franconi Enrico wrote:
> Hi Pierre-Antoine,
> Your example emphasises exactly my point of never allowing a RDF-star 
> graph to contain unstar: predicates.
I wouldn't like to restrict the kinds of IRIs that people can use, but...
> In my view, unstar: predicates are only useful to suggest an easy but 
> sound and complete  implementation of RDF-star entailments via RDF-1.1 
> simple entailment.

...yes, that's also how I view it.

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:"
> 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. Otherwise I don't understand ;)

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

> 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?
> Cheers
> —e.
>
>> On 20 Mar 2023, at 10:56, Pierre-Antoine Champin 
>> <pierre-antoine@w3.org> wrote:
>>
>> 
>>
>> Hi Enrico,
>>
>> during our conversation last Friday, I promised a discussion about 
>> the unstar mapping defined in the CG Report  
>> (https://www.w3.org/2021/12/rdf-star.html#dfn-unstar).
>>
>> What you said (or at least what I understand you said) was: given an 
>> RDF-star graph G, G and unstar(G) have the same entailments. I 
>> disagree with this assertion (see 1 below), but I agree with a weaker 
>> version of this assertion (see 2 below).
>>
>>
>> *1. I disagree with the assertion*
>>
>> Consider the following RDF-star graph G (serialized in Turtle, 
>> assuming the appropriate prefix declarations):
>>
>>     ex:a unstar:subject ex:b.
>>
>> unstar(G) is the following:
>>
>>     ex:a unstar:subject_ ex:b.  # notice the underscore at the end of 
>> the predicate
>>
>> which entails G'
>>
>>     ex:a unstar:subject_ [].
>>
>> unstar(G) entails G', however, G does not entail G'!
>>
>> On the other hand, consider the RDF-star graph H:
>>
>>     ex:a unstar:subject [].
>>
>> We can see that unstar(H) = G'
>> (that is, assuming that "[]" in both Turtle sources refer to the 
>> *same blank node*)
>>
>> Since unstar(G) entails unstar(H), it follows that G entails H. 
>> However, unstar(G) does not entail H.
>>
>> So G and unstar(G) both entail a graph that is not entailed by the other.
>>
>>
>> *2. I agree with a weaker version of the assertion*
>>
>> Granted, my examples above are somewhat pathological, because I use 
>> the 'unstar:' vocabulary in the RDF-star graph. Since we want to 
>> avoid nasty interactions with this kind of pathological triples and 
>> the triples produced by the unstar mapping, we use a form of 
>> escaping, which is why, in my counterexample above, G and unstar(G) 
>> have different entailments.
>>
>> If we restrict ourselves to "nice" RDF-star graphs, i.e. RDF-star 
>> graphs that /do not/ use the 'unstar:' vocabulary, then we can assert :
>>
>>   for any "nice" RDF-star graph G containing no quoted triple, then G 
>> = unstar(G)
>>   (and therefore G and unstar(G) have the same entailments!)
>>
>> Note that, for any "nice" RDF-star graph that contains some quoted 
>> tripes, there are some entailments of unstar(G) that are /not/ 
>> entailedby G. E.g., unstar(G) will always entail
>>
>>   [] unstar:subject [] .
>>
>> while G will not (because, being nice, it contains no triple with 
>> predicate unstar:subject).
>>
>> Note also that there are also some entailments of G that are not 
>> entailed by unstar(G). For example, G entails itself, while unstar(G) 
>> can not entail anything that contains quoted triples (being an RDF 
>> 1.1 graph).
>>
>>   best
>>
>>
>>
>>
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>