Re: New proposal for RDF* Semantics

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

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

   pa