Re: Some reflections on the semantics of embedded triples

Hi Antoine,

thanks for this detailed review of the proposed semantics.

On 30/11/2020 15:25, Antoine Zimmermann wrote:
> In the current semantics, blank nodes that appear in embedded triples 
> are behaving differently from blank nodes outside. This leads to 
> peculiarities of semantics with possibly unforseen consequences.
>
> TL;DR: In short, blank nodes inside embedded triples can be understood 
> as "placeholders", as opposed to existentials when they are outside 
> embedded triples.

You can say that.

I would rephrase it like that:

* blank nodes appearing only in asserted triples (i.e. standard RDF 
blank nodes) are existential variable ranging over resources from the 
domain (as they always were)

* blank nodes in embedded triples are existential variables ranging over 
ground terms (although if they also appear in asserted triples, the 
ground term is interpreted in those asserted triples as a resource from 
the domain)

>
>
> ==Long comments:==
>
> One consequence is that it is not possible to directly refer to 
> triples with blank nodes. For instance, if I say:
>
> << _:b <p> <o> >>  onto:source ex:somewhere .
>
> it does not mean that a triple with a bnode in subject position is 
> found somewhere. It means that there is a ground triple following the 
> template
>
> ?s <p> <o>
>
> that relates to ex:somewhere via relation onto:source.

Indeed.

Note that this is consistent with how blank nodes behave in standard 
RDF: I can not refer to a blank node used by someone else.

If file1.ttl contains:

     ex:alice ex:likes [ ex:name "Bob" ].

I have no way to say, in another file, something like

    "That person that Alice likes (according to file1.ttl) is owl:sameAs 
<http://example.com/users/bob>."

(at least not in practive -- even though it is theoretically possible in 
the abstract syntax)

> Also, while the triple:
>
> << <s> <p> "042"^^xsd:integer >> onto:source  ex:somewhere .
>
> must be derived from data that has "042" rather than "42", the triple:
>
> << <s> <p> _:b42 >>  onto:source ex:somewhere .
>
> can be derived from anything that follows the template:
>
> << <s> <p> ?x >>  onto:source ex:somewhere .
Yes. Because, as Dörthe explained, _:b42 is quantified outside the 
embedded triple.
>
> If we use the "embedded-triple-as-quotation" metaphore, then if we say:
>
> Mike says "Joe is in the house". (:mike :says << :joe :in :house >>)
>
> we cannot conclude:
>
> Mike says "someone is in the house". (Joe replaced by an existential)

I would argue that Mike didn't use the word "someone", so you should not 
conclude that.

More formally, you should not conclude

     Mike says "there exists someone who is in the house"

because he didn't say that.

>
> but we can conclude:
>
> Mike says "______ is in the house". (Joe replaced by a placeholder)

This is also an existential, only quantified outside the whole sentence:

     The exist someone who Mike says "is in the house"

> This may be a problem for a number of use cases where one wants to 
> faithfully refer to triples with blank nodes.
It may. But again, this inability to refer to blank nodes inside someone 
else's graph is already commonplace in RDF (and one of the main reason 
why so many people hate them).
>
>
> There are also bizarre (or seemingly bizarre) things happening when we 
> try to extend the current semantics to more expressive regimes.
>
>
> Some examples that are not necessarily intuitive:
>
> # Example 1
> << <a> <b> "42"^^xsd:integer >> <x> <y> .
> <s> <p> "042"^^xsd:integer .
>
> entails (recognising xsd:integer):
<< <a> <b> "42"^^xsd:integer >> <x> <y> .
<s> <p> "42"^^xsd:integer .

which in turns entails

>
> << <a> <b> _:x >> <x> <y> .
> <s> <p> _:x .
and that does not strike me as shocking. ;)
>
> # Example 2
> << _:x <b> <c> >> <p> << _:y <b> <c> >> .
> _:x owl:sameAs _:y .
>
> does not entail (in RDFS-plus):
>
> << _:x <b> <c> >> <p> << _:x <b> <c> >> .

If you come back to my interpretation above; _:x and _:y appearing in 
embedded triples forces them to range over ground terms. The 2nd triple 
forces those ground terms to denote the same thing, but /not/ to be 
identical. That's why the resulting triple is not entailed.

I agree that this is counter-intuitive, though...

>
> # Example 3
> << <clark> <can> <fly> >> owl:sameAs << <superman> <power> <flight> >> .
> <clark> a <journalist> .
>
> entails (in RDFS-plus):
>
> <superman> a <journalist> .
>
> but does not entail:
>
> << <clark> <can> <fly> >> owl:sameAs << <superman> <can> <fly> >> .

Yew, that one is indeed bizarre! 8-/

It is a consequence of the last part of item 6 in 
https://w3c.github.io/rdf-star/rdf-star-cg-spec.html#definitions . The 
rationale is that "a given triple states at most one thing" (but the 
same thing can be stated by different triples).

I agree that this is counter intuitive, but as Peter, I would be tempted 
to blame it on owl:sameAs, and its famous tendency to be a foot-shooter.

Maybe what you really meant here is rdfx:equivalentStatement, stating 
that triples /state/ the same thing (i.e. their subject, predicate and 
object respectively denote the same thing) although they remain 
/different/ triples? In other words, same extension, different intension?