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

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, 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 comparable to the :ID attribute in RDF/XML.

+

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). The properties may provide a hint at the intended semantics. 

+

Both "modes" used side by side would solve this problem:

 << :a :b :c >> :denies :d .
 :a :b :c {| :exclaims :e |}

This leads me to the conclusion that RDF*/PG and RDF*/AS have different semantics, 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, providing a syntactic link between an actual assertion and annotation(s) on it. 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, 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.


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.

Received on Monday, 16 November 2020 13:46:25 UTC