Re: New proposal for RDF* Semantics

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

As an aside, RDF interpretations must recognize xsd:string, and must 
ensure that IEXT(rdf:type) contains (x, I(aaa)) for any value x of any 
recognized datatype aaa. So even basic RDF entailment adds many nodes to 
(entailed) RDF graphs.

As a second aside, consider RDF-entailment recognizing D where D 
contains owl:real. Now, IEXT(rdf:type) contains an uncountable amount of 
pairs (x, I(owl:real)). Many of them do not even reflect as entailed 
triples, because their x has no lexical value, hence no literal to 
denote it in all interpretations. So the mere occurrence of something in 
IEXT(some property) does not automatically make it pop as a node in RDF 
graphs. For this, we also need a /term/ that consistently denotes that 
something.

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

   best