Re: New proposal for RDF* Semantics

On 1/12/21 3:29 AM, Pierre-Antoine Champin wrote:
>
>
> On 08/01/2021 19:56, Peter F. Patel-Schneider wrote:
>> Oops, I mixed up RDF graphs and RDF intepretations.  This makes some of my
>> complaints incorrect.
>>
>>
>> On 1/8/21 1:22 PM, Pierre-Antoine Champin wrote:
>>
>>> On 08/01/2021 17:05, Peter F. Patel-Schneider wrote:
>>>> What advantages does this semantics have over a mapping to RDF reification?
>>> RDF reification is referentially transparent, while this proposal keeps IRIs
>>> and literals in embedded triples referentially opaque. 
>> But it is possible to use an extended mapping to achieve referential opacity.
> I am not sure what you mean by "extended mapping" here.


See my previous message, which has a modification of a mechanism for extending
RDF reification that achieves partial referential opacity and refers back to a
previous message on the topic.

>>>>> I also do not understand why S*, etc., need special semantics.
>>> This is to ensure the uniqueness  (or literal-ness, if you like) of embedded
>>> triples. More precisely, any node x with the three triples (x, S*, s), (x,
>>> P*, p) and (x, O*, o) is bound to denote the triple (s,p ,o), in all
>>> interpretations.
>> It is possible to achieve this by other means, which does not require
>> properties with special semantics.
> I couldn't find any, but I am all ears :-) 


See my previous message.

>>>>> And one big disadvantage of this semantics is that all literals, all blank
>>>>> nodes, and all literals will be nodes in the RDF graphs.
>>> What exactly do you mean by "the RDF graphs"? Clearly, you don't mean "all
>>> RDF graphs"... By definition, the empty set of triples is an RDF graph, and
>>> it does not contain all those nodes.
>>>
>> I should have said "in interpretations", not "in [...] RDF graphs".  My mistake.
>>> I agree, though, that any RDF graph /entails/ bigger graphs, containing
>>> (possibly infinitely) many triples with S*, P* and O* as their predicate. Is
>>> that a problem? I don't think so.
>>>
>> Because the interpretations will contain analogues to all blank nodes any
>> construction that needs a fresh blank node might not work as expected.
>
> In my understanding, the notion of "fresh" blank node is relative to a graph
> (i.e., a blank node that does not appear in that particulat graph).
>

If something is fresh then it should have no special features.  If all blank
nodes are in all RDF* interpretations then it is possible that they all have
special features and asking for a fresh blank node relative to an RDF* graph
could be problematic.

> If the graph is finite (which is the case in most, if not all, practical
> situations), there is obviously no problem.
>
> If the graph is infinite (which is allowed by the definition), the situation
> might be trickier: one could define an infinite RDF or RDF* graph containing
> all blank nodes, for which no "fresh" blank node would be left for applying
> the mapping. This can be solved through a clever renaming of blank nodes
> before applying the mapping (alla Hilbert's Hotel
> <https://en.wikipedia.org/wiki/Hilbert%27s_paradox_of_the_Grand_Hotel>).
> Note that this "problem" is not created by the proposed RDF* semantics: it
> already arises with the definition of merging
> <https://www.w3.org/TR/rdf11-mt/#dfn-merging> in RDF11-MT (imagine you have
> to merge two infinite graphs, each containing all blank nodes?).
>
> So I believe that, for any RDF* graph, we always have enough fresh blank
> nodes at our disposal. I fail to see how the definition of RDF*
> interpretation has any influence of that
>
It does because the construction places all blank nodes in all RDF*
interpretations.
>>> While RDF* interpretations provide such terms for any IRI or literal,
>>> through the D* datatype, they do not provide such terms for blank nodes.
>>>
>>> As for IRIs, literals and ground RDF* triples, there are many of them, but
>>> not "more" than strings (as they can all be serialized), so why would this
>>> be a problem with RDF* if it is not a problem with RDF? :-)
>>>
>> I expect that the requirement that all RDF* triples, all IRIs, and all RDF
>> literals show up in RDF* interpretations is not a problem.  But having all RDF
>> blank nodes show up might be.
>
> I believe that it is important that non-ground triples are included in
> interpretations. Consider the following example:
>
>   <file.ttl>
>       :content """
>           @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
>           <#Unicorn> a rdfs:Class.
>           [] a <#Unicorn>.
>       """;
>       :contains << _:x a <file.ttl#Unicorn> >>.
>
> If interpretations contained only ground triples, then the last assertions
> (with the :contains predicate) could be argued to be inaccurate (because
> file.ttl contains no ground triple of that form).
>
> That being said, as we have no way to precisely reference a given blank
> node, we don't need to have all of them in an interpretation... An infinite
> strict subset of the set of all blank nodes would work just as well, I
> guess... That would make the definition a little cumbersome, but if you
> think that would prevent problems down the line, maybe that's worth the trouble.
>

It is not obvious that RDF* interpretations have to include triples at all.  

>   pa
>

Received on Tuesday, 12 January 2021 16:15:23 UTC