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

TL;DR:  Using blank nodes for embedded triples leads to the RDF* version of
referential transparency.  Using fresh IRIs leads to complete opacity.  Using
IRIs that encode the subject, predicate, and object leads to referential
opacity.  Anything else is tricky and probably not useful.


Consider the following RDF graphs:

G1)
:Mary :said _:s1 .
_:s1 rdf:type rdf:statement .
_:s1 rdf:subject :John .
_:s1 rdf.predicate :saw .
_:s1 rdf:object :cc .

G2)
:Mary :said _:s2 .
_:s2 rdf:type rdf:statement .
_:s2 rdf:subject :John .
_:s2 rdf.predicate :saw .
_:s2 rdf:object :cc .

G3)
:Mary :said _:s3 .
_:s3 rdf:type rdf:statement .
_:s3 rdf:subject :John .
_:s3 rdf.predicate :saw .
_:s3 rdf:object :sm .

G44)
:Mary :said s:s4 .
s:s4 rdf:type rdf:statement .
s:s4 rdf:subject :John .
s:s4 rdf.predicate :saw .
s:s4 rdf:object :sm .

G5)
:Mary :said s:s5 .
s:s5 rdf:type rdf:statement .
s:s5 rdf:subject :John .
s:s5 rdf.predicate :saw .
s:s rdf:object :sm .



We get various entailments and non-entailments between these graphs,

First, G1 entails G2.
If the denotation of :cc is the same as the denotation of :sm, then we also get
 G1 entails G3
Using blank nodes for embedded statements in RDF* makes them referentially
transparent, at least as far as RDF* can model referential transparency.

Second, G4 does not entail G5, even though the statement arguments are exactly
the same.
This holds true even for blank nodes as arguments.
Using different IRIs for RDF statements gives a completely opaqueness, let
alone referential opaqueness.

Third G4 entails G4.
If RDF* determines the IRI for embedded blank nodes by using an injective
mapping from triples embedded triples then such triples are only referentially
opaque.

I had thought that it might be possible to produce something useful by
employing non-injective mappings when determining the IRI for an embedded
triple.   But this approach has potential problems because embedded statements
with different subjects, predicates, or objects will end up being the same. 
Even if the the only thing that mapping is insensitive to is the actual
identity of blank nodes then you end up with situations like:

:Mary :said s:Johnsaw_ .
s:Johnsaw_ rdf:type rdf:statement .
s:Johnsaw_ rdf:subject :John .
s:Johnsaw_ rdf.predicate :saw .
s:Johnsaw_ rdf:object _:b1 .

:Mary :said s:Johnsaw_ .
s:Johnsaw_ rdf:type rdf:statement .
s:Johnsaw_ rdf:subject :John .
s:Johnsaw_ rdf.predicate :saw .
s:Johnsaw_ rdf:object _:b2 .

Here the statement s:Johnsaw_ has two objects, which appears to have
unintended consequences.  I have not yet convinced myself that there is no way
to make this work, although I do believe that there are unintended consequences.



peter




On 10/30/20 1:33 PM, thomas lörtsch 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 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). 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?
>
>> 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 Friday, 30 October 2020 18:53:38 UTC