Re: RDF* semantics, particularly malformed literals in embedded triples

On 05/02/2021 23:27, phayes@ihmc.us wrote:
>
>
>> On Feb 5, 2021, at 5:17 AM, Pierre-Antoine Champin 
>> <pierre-antoine.champin@ercim.eu 
>> <mailto:pierre-antoine.champin@ercim.eu>> wrote:
>>
>> Dear Peter and Pat,
>>
>> On 05/02/2021 01:53, phayes@ihmc.us wrote:
>>>
>>>
>>>> On Feb 4, 2021, at 1:56 PM, Peter F. Patel-Schneider 
>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>
>>>>
>>>> On 2/4/21 1:00 PM, Pierre-Antoine Champin wrote:
>>>>>
>>>>> On 04/02/2021 00:18, Peter F. Patel-Schneider wrote:
>>>>>> On 2/3/21 4:09 PM, Pierre-Antoine Champin wrote:
>>>>>>> On 28/01/2021 01:59, Peter F. Patel-Schneider wrote:
>>>>>>>> On 1/25/21 4:21 AM, Pierre-Antoine Champin wrote:
>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> One example of "missed" entailement would be (I think) with the
>>>>>>>>> "malformed-literal-bnode" test
>>>>>>>>> (https://w3c.github.io/rdf-star/tests/semantics/manifest.html#malformed-literal-bnode 
>>>>>>>>> <https://w3c.github.io/rdf-star/tests/semantics/manifest.html#malformed-literal-bnode>).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But granted, that one is a corner-case, that maybe not 
>>>>>>>>> everybody agrees on
>>>>>>>>> anyway.
>>>>>>>> I don't see why this entailment would be missed.
>>>>>>> (this is based on your proposal here:
>>>>>>> https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0059.html 
>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0059.html>)
>>>>>>>
>>>>>>> * the input of the test has an rdf*:object arc, but no 
>>>>>>> rdf:object arc
>>>>>>> (because o is a malformed litteral)
>>>>>>>
>>>>>>> * the expected entailed graph as a spurious rdf:object arc, and 
>>>>>>> misses the
>>>>>>> rdf*:object arc (because o is a blank node)
>>>>>> The example you mention is, I beleive,
>>>>>>
>>>>>> prefix :<http://example.com/ns# <http://example.com/ns#>>
>>>>>> prefix xsd:<http://www.w3.org/2001/XMLSchema# 
>>>>>> <http://www.w3.org/2001/XMLSchema#>>
>>>>>> << :a :b "c"^^xsd:integer >> :p1 :o1.
>>>>>>
>>>>>> when xsd:integer is a recognized datatype MUST entail
>>>>>>
>>>>>> prefix :<http://example.com/ns# <http://example.com/ns#>>
>>>>>> << :a :b _:x >> :p1 :o1.
>>>>> Correct
>>>>>> This stays, intuitively, that an embedded triple with a malformed 
>>>>>> literal
>>>>>> entails one with a blank node.
>>>>>>
>>>>>> I agree that my proposal does not have this entailment, contrary 
>>>>>> to my
>>>>>> previous impression.  But I view this as a good thing.  Malformed 
>>>>>> literals do
>>>>>> not denote in RDF so there should not be any thing for the blank 
>>>>>> node to
>>>>>> match.  So don't view this as a desireable entailment.
>>>>>
>>>>> I know this one is controversial. :)
>>>>>
>>>>> My position was: in RDF, one can replace any term with a fresh 
>>>>> blank node,
>>>>> and the resulting graph is entailed by the original one. Following the
>>>>> principle of least surprise, the same should hold in RDF*.
>>>>
>>>>
>>>> Well, a surprise is that malformed literals in embedded triples do 
>>>> not cause a
>>>> semantic inconsistency like they do elsewhere.
>>
>> Is it?
>>
>> Embedded triples are not asserted,
>>
> Ah, I guess I have not been keeping up with all the changes.
No one can blame you for that! :)
> The last time I checked, embedded triples /were/ asserted.

At some point, yes. Then there was the proposal of having to different 
modes (SA and PG). The current (and hopefully stable) state of the draft is

* using an embedded triples ( << ... >> ) does not assert it (so the SA 
mode is the norm)

* Turtle* provides a way to annotate an asserted triple, i.e. assert it 
and use it embedded in the same expression. This reads like this:

     :me :travelTo :Berlin {| :on :Wednesday |}.

and is syntactic sugar for

     :me :travelTo :Berlin
     << :me :travelTo :Berlin >> :on :Wednesday.

This has been documented in the CG report:

https://w3c.github.io/rdf-star/rdf-star-cg-spec.html#sa-mode-and-pg-mode


> But now I am confused.
>
> Certainly examples using 'alice said <<foo>>' push intuitions that 
> way, but other threads are discussing examples like
>
> <<:me :travelTo :Berin>> :on :Wednesday .
>
> which surely seems like it should entail
>
> :me :travelTo :Berlin .

See Thomas' answer: his original example  contained both the asserted 
trile and the annotation.

>
> and it seems to be about :Berlin, the city, rather than ":Berin" the 
> URI. So are y'all on the same wavelength?

On the question "is the embedded triple asserted or nor", I think we are.

On the question of referential opacity vs. referential transparency, 
there are indeed some discussions.

The point I have been making in favor of referential opacity is that it 
is more flexible. In other words, use-cases that require referential 
transparency can be addressed with referentially-opaque triples, but the 
opposite is not true.

In the "travel to Berlin" example above, of course that the annotation 
(:on :Wednesday) is not about the triple itself, but about the situation 
described by the triple. It seems to me that, as along as we agree that 
this is the semantics of the predicate :on, and we use it consistently, 
this is not a problem.

Similarly, consider a predicate :heightInCm, whose range would be 
xsd:decimal :

     :monalisa :heightInCm "77"^^xsd:decimal.

The height of the Mona Lisa is not a decimal number, but we understand 
the predicate to implictly refer to an intermediate concept (a physical 
length), which in turns is related to the decimal value.

Does this make sense?


>
> Pat
>
>> so their truth value should have no impact on the truth value of the 
>> graph. For example, does it surprise you that:
>>
>>   :alice :says << _:x a owl:Nothing >> .
>>
>> is satisfiable ?
>>
>> Is this really different from
>>
>>    :alice :says << :alice :age "notaninteger"^^xsd:integer >>.
>>
>> ?
>>
>>>>    So given that there is a
>>>> surprise already, further surprises are not indicative of further 
>>>> incorrect
>>>> behaviour.
>>>>
>>>> The argument the other way is that malformed literals do not denote 
>>>> anything,
>>>> so there is nothing for the blank node to denote, so the entailment 
>>>> should not
>>>> follow.
>>>
>>> Yes, and that argument is correct. This entailment:
>>>
>>> x:a x:b 'notaninteger'^^xsd:integer .
>>> entails
>>> x:a x:b _:thing .
>>>
>>> is valid in RDF (recognizing XML schema datatypes) not because it 
>>> preserves truth, but because the antecedent is necessarily false in 
>>> all interpretations. It is a trivial /ex falso quodlibet/ entailment.
>>
>> It is indeed :-) But to be fair, that was not the rationale behind 
>> the incriminated test-case.
>>
>> The current idea is that IRIs and literals in embedded triples are 
>> not referentially transparent, so that we can "talk about" any 
>> triple, even inconsistent ones (see my examples above). So the 
>> premise of the test-case would /not/ be inconsistent, and the 
>> expected result would be entailed, but not by /ex falso quodlibet/.
>>
>>   best
>>
>>> To emphasize the point, this is also a valid entailment, for exactly 
>>> the same reason:
>>>
>>> x:a x:b 'notaninteger'^^xsd:integer .
>>> entails
>>> https://dbpedia.org/resource/Pat_Hayes 
>>> <https://dbpedia.org/resource/Pat_Hayes> owl:sameAs 
>>> https://dbpedia.org/resource/Pablo_Picasso 
>>> <https://dbpedia.org/resource/Pablo_Picasso> .
>>>
>>> Pat Hayes
>>>
>>>
>