- From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Date: Thu, 19 Nov 2020 19:01:22 +0100
- To: Jerven.Bolleman@sib.swiss, public-rdf-star@w3.org
- Message-ID: <76ffeb19-9019-6664-3bf4-1f378a6dfc9b@ercim.eu>
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
Attachments
- application/pgp-keys attachment: OpenPGP_0x9D1EDAEEEF98D438.asc
Received on Thursday, 19 November 2020 18:01:28 UTC