Re: weakness of embedded triples

Peter,

thanks a lot for these insightful remarks.

While I consider some of the problems you raise to be features rather
than bugs (see below), I think you still point out some weaknesses in
the proposed semantics.

On 14/10/2020 18:51, Peter F. Patel-Schneider wrote:

> In https://w3c.github.io/rdf-star/ there is a section on referential opacity. 
> The main claim there is that triples are referentially opaque. 
>
>
> But embedded triples are much weaker than just being referntially opaque.  To
> see this consider the following RDF* graph under the RDF* version of RDF
> entailment recognizing xsd:decimal and xsd:integer.
>
> :loisLane :believes << :clarkKent :height "6"^^xsd:decimal >> .
>
> In this semantics "6"^^xsd:decimal means the same as "6"^^xsd:integer 

Not in simple entailment; this is only true in D-entailment (where D
includes both datatypes).

So in the following, I will assume that we are talking about
RDF*-extrapolated D-entailment

> so one
> would expect that
>
> :loisLane :believes << :clarkKent :height "6"^^xsd:integer >> .
>
> is RDF*-entailed.
Only if you assume that Lois knows that these literals are equal... In a
way, this is very similar to the Superman / Clark Kent scenario. So in
my view, this should not be expected in the general case.

Granted, equality between the two literals is somehow "necessary" in
D-entailment, while the equality between Superman and Clark Kent is
"contingent" to the graph. Hence, defining a semantic extension where
these inferences hold seems reasonable as well. Let's call this semantic
extension "datatype transparent entailment" or DT-entailment.

> But it is not.  There are two reasons for this.
>
> First, there is no requirement that satisfying interpretations for the first
> graph map < :clarkKent :height "6"^^xsd:integer > to anything 

DT-entailment would indeed have to ensure, in addition to the existing
semantic conditions, that all such "equivalent" triples are mapped by
IT... :-/

We did consider making IT a total mapping rather than a partial mapping,
but since IL is itself partial, it didn't seem to make much sense.

May be we could require that IT maps any RDF* triple made of IRIs,
literals in domain(IL), and blank nodes present in the graph?...

> and if a
> satisfying interpretation does map the triple there is no requirement that its
> ITEXT mapping gives the triple its correct meaning.  (The value of ITEXT for
> the triple could have the real number pi as its third element.)

You are right, the semantic condition on ITEXT should not be restricted
to the triples present in the graph, but to the whole domain of IT.

> Second, "6"^^xsd:integer is a different node from "6"^^xsd:decimal. So even if
> the intepretation treats the second embedded triple nicely, and thus gives it
> the same meaning as the first embedded triple, they are still two different
> triples and :loisLane can believe one but not the other.  So very little of
> the semantics of RDF gets into embedded triples.
Again, this is intended (at least for RDF* simple entailment, and RDF*
D-entailment)
> Each triple is, in effect, its own context.  So, in an RDFS version of RDF*,
> even if :loisLane believes several triples that should imply another, they
> generally don't.  For example:
>
> :loisLane :believes << :clarkKent rdf:type :man >> .
> :loisLane :believes << :man rdfs:subClassOf :human >> .
>
> Does not imply
>
> :loisLane :believes << :clarkKent rdf:type :human >> .

Yes, because, again, we don't want to bake into the semantics the
assumption that :loislane knows the inference rules of RDFS.

Furthermore, if you replace :believes by :disbelieves, your inference
would clearly be incorrect.

> So embedded triples are incredibly weak in RDF*.   Making them useful will
> likely require quite a bit of work.

Depends for what use, but yes; they are designed to be weak.

Hopefuly, they can be made stronger by semantic extensions, but I
confess that we have not yet had the time to explore this.

> On the other hand, there are some unusual inferences that can be made in
> RDF*.  In an RDF* version of RDFS++ it is possible to state that two triples
> are the same.   The graph
>
> :loisLane :believes << :superman :can :fly >>.
> << :superman :can :fly >> owl:sameAs << :clarkKent :can :fly >> .
>
> is consistent here and implies
>
> :superman owl:sameAs :clarkKent .
> :loisLane :believes << :clarkKent :can :fly >>.

I agree: these two triples are entailed.

I don't see why you consider the second one as surprising... You simply
replace one thing by its "same as".

I see how the first inferred triple can be slightly surprising, but I
don't see it as a flaw. If these two triples are the same, then their
intensions /and their extensions/ must be identical...

  best

>
>
>
> peter
>
>