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

> 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 <https://www.w3.org/TR/rdf11-mt/#dfn-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.
>>> 
>>> 
>>> 
>> 
> 
>