Re: New proposal for RDF* Semantics

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

>>> 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. 
>
> 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.
>
Agreed.  Just because something is entailed does not mean that it shows up in
RDF graphs.
>
> 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.
>
>   best
>

Received on Friday, 8 January 2021 18:56:47 UTC