W3C home > Mailing lists > Public > public-rdf-star@w3.org > February 2021

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

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 4 Feb 2021 14:56:01 -0500
To: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, public-rdf-star@w3.org
Message-ID: <3d8c7a5f-7053-25f5-da04-4fa264f9c8ca@gmail.com>

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).
>>>>> 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)
>>> * 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#>
>> prefix xsd:<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#>
>> << :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.   So given that there is a
surprise already, further surprises are not indicative of further incorrect

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

> But this causes strange corner cases, such as this test-case. In my
> proposal, this is what requires a slightly different treatment for so-called
> embedded blank nodes (which denote the term used in the triple) from mixed
> blank nodes (which denote either a term or the thing that term denotes,
> depending on where they appear).
> This is probably too complex. It's probably better to give up on that
> particular test case...

The test case is an interesting one.   The question is whether it should be
approved at this point.  When the semantics of RDF* are finally determined,
this test case should either be approved or rejected, because it *is* a corner
case, and corner cases are what stress implementations.
Received on Thursday, 4 February 2021 19:56:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 4 February 2021 19:56:16 UTC