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

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, 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
>
>