Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

Hi Thomas,

On 16/11/2020 14:46, thomas lörtsch wrote:
> Pat, thanks a lot for the clarification! You are of course right and I don’t know how I still managed to get it wrong. But let’s see if I really do understand now and what this leads to...
>
> RDF standard reification does reify an actual assertion,

I guess that is your interpretation of "a concrete realization of an RDF 
triple", but this does an "actual assertion" of the triple -- at list 
not from the person using reification. The spec clearly says "A 
reification of a triple does not entail the triple,", so I can reify a 
triple written seen in another document, /without asserting it myself/.

Reification is designed to allow this:

     prefix ct: <conspiracy_theory.ttl#>
     <conspiracy_theory.ttl> :contains [ rdf:subject ct:earth; 
rdf:predicate rdf:type; rdf:object ct:FlatThing ].

>   a triple token, and makes it possible to speak about the things that statement denotes - it works on the level of interpretations, not of the vocabulary and therefor is necessarily referentially transparent. What it is missing is a solid link between a specific triple token and its reification (the reification quadlet in standard RDF). RDF/XML does provide an :ID attribute to syntactically link an statement to its reification. But there is no formal semantics as RDF provides no model theoretic construct to represent a statement. The spec says: "This requires triple tokens to exist as first-class entities in the universe IR of an interpretation." [0] and as far as I can see they don’t, yet.
>
> +
>
> For RDF* this means that PG mode is quite similar to RDF standard reification as the annotated statement is indeed asserted. Also the proposed syntax
>
>  :a :b :c {| :d :e |}
>
> provides a solid syntactic link between statement and annotation

At the level of the /concrete/ syntax, yes.

At the level of the /abstract/ syntax, no, because this is meant to be 
equivalent to

     :a :b :c.
     << :a :b :c >> :d :e.

> comparable to the :ID attribute in RDF/XML.
Actually, the :ID attribute in RDF/XML is more expressive than RDF*/SA, 
because you can assert the same triple several times, with different IDs.
> +
>
> RDF* in SA mode OTOH has no equivalent in RDF standard reification as RDF doesn’t formalize the notion of an unasserted assertion as an abstract object. RDF* in SA mode is very similar to a literal quote of a statement, but additionally the triplet representation of a statement supports querying, blank nodes and name spaces:
>
>  << :a :b :c >>
>
> However there is a problem with SA mode: an actual assertion and a quote of some assertion of that kind are not linked formally and not even syntactically. See for example:
>
>  :a :b :c .
>  << :a :b :c >> :denies :d .
>  << :a :b :c >> :exclaims :e .
>
> It’s impossible to tell who asserted ":a :b :c" - :d or :e (or somebody else).
It is the /author/ of the Turtle* filr who asserted :a :b :c, and that 
may be a totally different person than :d and :e.
>   The properties may provide a hint at the intended semantics.

Exactly.

Or, if really you want to track which utterance of the triple lead the 
author to endorse it, you can add another level of annotation:

     << << :a :b :c >> :exclaims :e >> :trustedBy <>.

or something like that.

> +
>
> Both "modes" used side by side would solve this problem:
>
>  << :a :b :c >> :denies :d .
>  :a :b :c {| :exclaims :e |}

No, because his concrete syntax would produce exactly the same abstract 
syntax as your previous example -- at least in my understanding, but I 
trust that Olaf would agree (see 
https://github.com/w3c/rdf-star/issues/9#issuecomment-708608422 
<https://github.com/w3c/rdf-star/issues/9#issuecomment-708608422>).

 From the very beginning, embedded triples in RDF* are totally 
identified by their subject+predicate+object, there is now way to 
distinguish different mentions (tokens) of the same triple. As I 
understand, this was a deliberate design choice.

> This leads me to the conclusion that RDF*/PG and RDF*/AS have different semantics,
Neither has a definite semantics yet; this is what this discussion is 
about. But my preference goes to considering PG as syntactic sugar for a 
frequent pattern in SA.
>   different syntactic features and could live side by side, serving different purposes. But RDF*/PG and RDF*/AS are not alternatives to each other and can’t be used interchangeably.
>
> RDF*/PG is indeed syntactic sugar for RDF standard reification,

No, because standard reification does *not* entail the reified triples.

And also, maybe no, because standard reification is referentially 
transparent, while referential transparency/opacity is still under 
discussion for RDF*.

> providing a syntactic link between an actual assertion and annotation(s) on it.
Standard reification does that, but RDF* (either in PG or SA mode) does 
not. And this does not depend on the (to be defined) semantics, it is a 
consequence of the /abstract syntax/, in which RDF* triples identity is 
entierely defined by their subject+predicate+object.
> In that respect it is a good alternative to RDF/XML with its :ID attribute. With a proper model theoretic definition of the notion of a triple token it could complete the semantics of RDF standard reification.
>
> RDF*/SA however provides something that has no equivalent in RDF: a way to quote abstract/unstated/possible statements,

Standard reification does that, although "quoting" is not the best way 
to describe it, because it seems to imply referential opacity.

>   plus support of namespaces, bnodes and querying. While it does not support a solid link between an asserted statement and annotations to such statement it might still be a useful addition to RDF. If those abstract statements should be referentially opaque or transparent is another question.

Agreed, the token-type distinction, and the opaque-transparent 
distinction, are orthogonal.

   pa

>
>
> Thomas
>
>
> [0] https://www.w3.org/TR/rdf11-mt/#reification
>
>
>> On 10. Nov 2020, at 17:35, Patrick J Hayes <phayes@ihmc.us> wrote:
>>
>>
>>
>>> On Oct 30, 2020, at 12:33 PM, thomas lörtsch <tl@rat.io> wrote:
>>>
>>> Okay, after some pondering I give up...
>>>
>>>> On 29. Oct 2020, at 15:48, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>>
>>>> It is entirely possible that RDF* could just use RDF(S) semantics for embedded
>>>> triples.  If RDF* is simply a shorthand for existing RDF(S) idioms then the
>>>> semantics of embedded triples can just fall out of the expansion of the RDF*
>>>> shorthands.
>>>>
>>>> The question is whether RDF* can be such a shorthand.  This depends on what
>>>> the desired meaning of RDF* constructs is.
>>>>
>>>> RDF semantics is quite flexible with respect to reified statements
>>> I was under the impression that there simply is no formal semantics in reification
>> The semantics specified for reification is not /normative/, but it does exist and is clearly stated, with examples, in the RDF semantics document. And you have it exactly backwards:
>>
>>> and also only loose informal semantics: the reification quadlet doesn’t describes any concrete statement but an abstract statement type (or, more precisely, the type of statements with some specific subject, predicate and object as indicated by the quadlet).
>> Wrong. From the published semantics document (https://www.w3.org/TR/rdf11-mt/#reification):
>>
>> "The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of composition or provenance information are applied to the reified triple, which are meaningful only when thought of as referring to a particular instance or token of a triple.”
>>
>>> Or do you mean with "flexible" that there is a lot of wiggle room to define a tighter semantics?
>>>
>>>> and there
>>>> are several ways to map RDF* embedded triples into reified statements.  Some
>>>> ways achieve a form of referential transparency and other achieve a form of
>>>> referential opacity.  For example, if an embedded triple is mapped into a
>>>> blank-node reified statement then the semantics of embedded triples is quite
>>>> transparent.  On the other hand, if an embedded triple is mapped into a
>>>> reified statement using a fresh IRI then the semantics of embedded triples is
>>>> extremely opaque.
>>> Here you lost me completely. While the whole concept is very surprising already, at the least I would have expected that mapping an embedded statemet into a blank-node reified statement would provide opaque reference (and vice versa with reified statements using a fresh IRI). Because, hmmm… blank nodes are very local, harder to get hold of by entailment engines etc... mummlbe mutter…? What am I missing?
>> Note, RDF reification is defined to be NOT opaque (in the sense of ‘referential opacity’) throughout. Again from the published specs:
>>
>> "Reification is not a form of quotation. Rather, the reification describes the relationship between a token of a triple and the resources that the triple refers to. The value of the rdf:subject property is not the subject IRI itself but the thing it denotes, and similarly for rdf:predicate and rdf:object. For example, if the referent of ex:a is Mount Everest, then the subject of the reified triple is also the mountain, not the IRI which refers to it.”
>>
>> That is, reification does not treat URIs opaquely. So ex:ClarkKent and ex:Superman mean the same thing inside a reified statement as they do outside it.
>>
>> Just wanted to get this point clear, as we took some pains to be precise about it in the WG discussions, both in 2004 and in 2014.
>>
>> Pat Hayes
>>
>>>> In the middle, an embedded triple could be mapping into a
>>>> reified statement using an IRI that is based on the syntax of the embedded
>>>> triple.  The semantics of embedded triples then depend on the details of this
>>>> mapping.
>>> The urn:rdf:triple:… idea would seem to fall into that category. Wouldn’t that even allow to define constructs like urn:rdf:triple:opaque:… and urn:rdf:triple:transparent:… ?
>>>
>>> Thomas
>>>
>>>
>>>> peter
>>>>
>>>>
>>>>
>>>> On 10/29/20 5:07 AM, Pierre-Antoine Champin wrote:
>>>>> On 29/10/2020 01:14, thomas lörtsch wrote:
>>>>>
>>>>>>> On 28. Oct 2020, at 19:31, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
>>>>>>>
>>>>>>> (...)
>>>>>>>
>>>>>>> RDF(S) semantics makes no distinction between "stated triples" and "inferred triples". So unless we change the semantics of RDF (!),
>>>>>> !!
>>>>> Yes, I wrote that, and you seem to imply that I am contradicting myself,
>>>>> but I don't think I am ;-)
>>>>>
>>>>> RDF(S) semantics knows nothing about "embedded triples", which are
>>>>> neither "stated" (I should probably have written "asserted") nor
>>>>> "inferred". So it is up to us to decide how this new kind of triples
>>>>> should be handled. This is what this whole discussion is about.
>