Re: Action point: discussing contra use case against referential opacity

On 14/11/2020 10:34, Jerven Tjalling Bolleman wrote:
> Hi All,
>
> During yesterdays first meeting we discussed the for and against of 
> referential opacity.
> As usual, speaking my thoughts came out mumbled and I am writing this 
> down.
> Where I hope my thoughts are clearer, but do feel free to correct any 
> misunderstanding on my side! or ask for clarification.
>
> TL;DR; referential opacity: allows one use case, but not another at 
> the cost of not being rdf reification surface syntax compatible.
>
> Regards,
> Jerven
>
>
> # Consequence of introducing referential opacity in the face of 
> reasoners.
>
> Currently there is the option that.
>
>   :loisLane :believes << :superman :can :fly >>.
>
> is RDF equivalent to.
>
>   :loisLane :believes [ rdf:subject :superman ; rdf:predicate :can 
> rdf:object :fly ; a rdf:Statement ] .
To be clear: this is one of the options documented in Olaf's paper, but 
that is /not compatible/ with the currently proposed (referentially 
opaque) semantics. And also to be clear, the currently proposed 
semantics was designed in collaboration with Olaf...
>
>
> where normal RDFS/OWL etc. reasoning is allowed to apply.
>
> i.e. :superman owl:sameAs :clarkKent would allow to infer
>
>   :loisLane :believes [ rdf:subject :clarkKent ; rdf:predicate :can 
> rdf:object :fly ; a rdf:Statement ] .
>
> because a triple [] rdf:subject :superman is just a normal triple, and 
> reasoning affects it.
Correct
>
> If we go for total referential opacity as a hard requirement then this 
> is not a valid consequence.
> And we end up with a world where it is not possible that RDFstar is 
> just a surface syntax for RDF Reification.
Correct.
>
> So that was the use case of preserving pure provenance in the face of 
> reasoner, but I believe the smushing of references has valid use cases 
> as well.

I agree.

But the problem is: if we smush references in the core model, there is 
no way for specific applications to "unsmush" them, even if they needed to.

On the other hand, if RDF* ensures referential opacity,  << :superman 
:can :fly >> and << :clark :can :fly >> are by default considered as 
different things. Some application may apply a specific extensions (as 
OWL does for plain RDF) and decide that they are actually the same.

>
>
> Given
>
>   << :bestMusicMakerEver :makesGreat :Music >> :believedBy :jerven
>
> Then the question is, which is the :bestMusicanEver that jerven 
> believes something about? and the consequences of that belief are 
> different if
>
>   :bestMusicMakerEver owl:sameAs :Bach .
> or
>   :bestMusicMakerEver owl:sameAs :AlanWalker .
>
> However, if all you want to do is find out what Music I like, then it 
> is really helpful if the references are no longer opaque after 
> reasoning. Because that is why one normally runs a reasoner.
>
> That said, this is not an issue that PGs solve because they don't have 
> a method to state referential equality. Which is why, e.g. in Neo4J 
> tutorials the modelling of :Superman and :clarkKent are done via 
> persona's (different IRIs). So to me with referential opacity we need 
> to do a lot of work, to avoid the issues with "bad" owl inferences 
> after smushing data together, which makes it more difficult to work 
> with "good" owl inferences after mushing data together. My opinion is 
> that it is important that we can work nicely with "good" owl 
> inferences in the RDFstar world as that is where my interest lies. e.g.
>
>   << _:1 :causesDisease :x >> :supportedBy :ClinVarEvidence1 .
>   _:1 owl:sameAs :mutationY .
>
> Then I do want the inference
>
>   << :mutationY :causesDisease :x >> :supportedBy :ClinVarEvidence1 .
>
> And referential opacity would forbid it.

No it wouldn't... Blank nodes are different from IRIs and literals in 
that respect, and we had a hard time ensuring that, despite referential 
opacity for other nodes, the inference you described just above still holds.

Blank nodes are not names, they are variables, so they are not concerned 
by referential opacity.

   pa

Received on Thursday, 19 November 2020 18:01:28 UTC