...

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

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

> If this entailment ends up as part of RDF*, then adding an rdf:object link to
> a fresh blank node for malformed literals would, I think, support this
> entailment without any negative effects.
>>>> Another more concerning example (IMO) is the one I pointed out in
>>>> https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0060.html. I
>>>> repeat it below for completeness:
>>>>
>>>> Consider the following RDF* graphs (serialized in Turtle*, assuming the
>>>> adequate prefix declaration) :
>>>>
>>>>        G1:  << :s :p :o >> a :A.
>>>>        G2:  << :s :p :o >> a :B.
>>>>        G3:  _:x a :A, :B.
>>>>
>>>> Does the merging of G1 and G2 entail G3? If you merge them before the
>>>> mapping (straightforwardly extending the definition of merging to the RDF*
>>>> abstract syntax), they do. And for that reason, I personally think they
>>>> should.
>>>>
>>>> If you merge them after the mapping, the merging will ensure that the blank
>>>> nodes generated respectively in G1 and G2 are distinct, and so the result
>>>> will *not* entail G3. The mapping from RDF* to RDF is lossy, as it does not
>>>> preserve the identity of RDF* embedded triples in the RDF abstract syntax.
>>> The blank node method for embedded triples does not preserve uniqueness when
>>> merging.  Implementations that perform merging have to use a modified version
>>> of merging.
>> ... and of union, I just realized (because the mapping of the union of two
>> RDF* graphs is not the union of the mapping of each of them).
>>
>> So the mapping from RDF* to RDF does not produce a "standard" RDF graph, it
>> produces an RDF-graph-that-needs-special-treatment-for-merging-and-union.
> No, RDF* implementations need to know what they are doing.  If they want to
> maintain uniqueness of triples across graphs they need to be careful about
> what operations they perform.
>
>> The whole mapping idea was (IIUC) to get rid of the new kind of node that
>> RDF* introduced. But in effect, the blank nodes used to represent embedded
>> triples require a special treatment for union and merging. I can't help but
>> consider them as a somewhat new kind of blank node...
>>
>> It seems to me that the extra machinery that you insist on keeping out of
>> the semantics shows up elsewhere... I still don't understand why you prefer
>> it that way, but I guess I could live with that. I'll try to capture that in
>> a PR.
>>
>>>> I don't have any idea right now on how to make a lossless mapping. The
>>>> mapping proposed in PR81 is lossy as well, but the additional machinery in
>>>> the semantics aims at re-introducing the missing information, i.e. two blank
>>>> nodes representing triples with the same subject, predicate and object are
>>>> forced to denote the same thing.
>>>>
>>>> Maybe there is a simpler solution to avoid the "merging issue" described
>>>> above -- and I am all for simplicity. But I think this issue needs
>>>> addressing.
>>>>
>>>> Or do you consider that this "merging issue" is not a problem?
>>> I do wonder whether any RDF implementations actually merge RDF graphs.
>> Maybe not explicitly. But all implementations I know allow you to load
>> multiple files into a single graph object, and they ensure that blank nodes
>> coming from each (graph parsed from a) file do not clash. Effectively, this
>> is a merge.
> You can consider this operation as constructing several graphs and then
> merging them.  You can also consider this operation as constructing one graph
> from multiple documents.  In RDF these are the same, but in my semantics for
> RDF* they are different.
>
>
>> To achieve the same thing in RDF*, some post-processing would have to be run
>> after loading each file, in order to merge blank nodes having the same
>> subject/predicate/object...
>>
>>> (Sometimes I wonder whether any RDF implementations actually compute RDF
>>> entailments.)
>> I have indeed never seen an implementation of RDF entailment alone, but RDFS
>> inference engines are meant to support it. Whether this is complete or
>> not... ;->
> Systems that perform RDFS inference don't implement RDF entailment, even as an
> intermediate operation, as far as I can tell.
>
>
>>    pa
>>