Re: RDF* and reification

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.

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.

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
>

Received on Wednesday, 3 February 2021 23:18:33 UTC