Re: Referential transparency and opacity

FWIW, and trying to steer away from the technicality: 

it is clear to me that on at least two topics (referential transparency and expressing occurrences) there is a sizeable rift  in the community of interested people, with major factions differing and on opposite sides. It also seems to me that both factions have strong and well justified motivations for their preferences. 

I believe that, in general, when you have two clearly justified opinions that are fundamentally opposite to each other, the right course of action is NOT voting so as to force one solution onto everybody through the strength of a 51% majority vote. The right approach instead is doubling the syntax. 

Having two syntaxes would provide the appropriate compromise: Anthony's proposal to have

- << s p o >> for quoted triples with referential transparency and
- <<" s p o ">> for quoted triples with referential opacity 

seems an elegant approach that satisfies everybody. I like it a lot: it detracts nothing for who needs opacity, and empowers those who need transparency to have a construct that does not depend on contextual declarations in every single graph they work with.   

Unless, of course, we are charged by the number of syntactic constructs we propose. 



Also, the same approach could be taken with occurrences. 

The idea that I cannot assign a URI to a quoted triple seems so weird to me. Giving one such option (option, not requirement!) would allow all discussions and misunderstandings about occurrences to disappear like snow in August. 

Think of how simpler would be discussing the marriage of Liz Taylor and Richard Burton, or the reliability of employee22 about the job title of employee 38 if I could assign different URIs for the same quoted triple. 

I am convinced that there is room to accommodate all these issues with a VERY LIMITED increase in syntactical complexity. 

Ciao

Fabio

P.S. How I wish the same choice had been done for RDF 1.1: we would now have two different named graphs, one as a container of triples and another as a quote of triples (i.e., one asserting and another non-asserting its content), and no endless debates about the lack of semantics of named graphs and their fundamental pointlessness because of that. 

--

> On 10 Feb 2022, at 14:38, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> 
>> Am 10.02.2022 um 12:43 schrieb Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>:
>> 
>> 
>> 
>> On 10/02/2022 09:45, Anthony Moretti wrote:
>>> I'm aware there are still semantics issues, but if they're potentially resolvable would it be possible to support both referentially transparent and referentially opaque statements by using a different syntax for each? So, I guess, something like:
>>> 
>>>    Referentially transparent statement:
>>>    << S R O >>
>>> 
>>>    Referentially opaque statement:
>>>    <<" S R O ">>
>> Here is a proposed alternative syntax :
>> 
>>    Referentially opaque statement:
>> 
>>    << S P O >>
>> 
>>    Referentially transparent statement:
>> 
>>    [ :transparentStatementOf << S P O >> ]
>> 
>> You would need to define the semantics of :transparentStatementOf accordingly. This could be done by
>> 
>> 1) making it an owl:InverseFunctionalProperty, so that
>>    X :transparentStatementOf << S P O >>.
>>    Y :transparentStatementOf << S P O >>.
>> 
>> entails that X and Y are one and the same thing.
>> 
>> 2) making it a transparency-enabling property (https://www.w3.org/2021/12/rdf-star.html#selective-ref-transparency), so that
>> 
>>    X :transparentStatementOf << S P O >>.
>>    S owl:sameAs S'.
>>    P owl:sameAs P'.
>>    O owl:sameAs O'.
>> 
>> entails
>> 
>>    X :transparentStatementOf << S' P' O' >>.
>> 
>> So, to the question "would it be possible to support both referentially transparent and referentially opaque statements", I would answer "yes, using the current specification of RDF-star" -- and the appropriate semantic extensions.
> 
> If I understand the CG report right such transparency-enabling semantics of some property have to be declared for every graph anew, right?
> 
> But obviously the main question is why the burden should lie on the referentially transparent use cases. The use cases in overwhelming majority are leaning towards referential transparency [0][1].
> 
> Sure there are other use cases that profit from referential opacity, but they are very special and close to the metal of the RDF machinery - and I deliberately say "profit", not "rely on", because I think there are much less troublesome ways to realize them. And b.t.w it would be good if the example from the Lotico talk wasn’t the only referential-opacity requiring example available that has been worked out to some degree.
> 
> Good engineering would suggest that the majority of use cases get the easy syntax while the niche cases have to go the extra mile. This also saves the niche case from getting trampled over. We saw how easy that happens with your very own recent blog post [2].
> 
> Therefore it seems to me that Anthony’s proposal is very reasonable and to the best of us all:
> - << … >> embedded triple would be syntactic sugar for standard reification
> - <<" … ">> embedded triple would serve the ExplainableAIversioning use cases
> - the quotes make it quite unmistable which semantics is applied
> - people that use RDF-star already don’t have to be re-educated
> - going the extra mile requires to type " and " which is really a very short mile
> - one can safely assume that who use those quotes really want the embedded triple to be referentially opaque (something that by the current proposal in practice we not can be sure about at all, rather to the contrary)
> - the concerns voiced by vendors about customers who don’t want to loose reasoning capabilities with RDF-star would go away
> - both semantics are already in place
> 
> Best,
> Thomas
> 
> 
> 
> 
> 
> 
> 
> 
> [0] https://lists.w3.org/Archives/Public/public-rdf-star/2021May/0023.html

> [1] https://lists.w3.org/Archives/Public/public-rdf-star/2021May/0032.html

> [2] https://lists.w3.org/Archives/Public/public-rdf-star/2022Jan/0092.html

> 
>>> With one usage rule:
>>> 
>>>    Transparent statements can only be nested in transparent statements.
>>> 
>>> The rule means that once the <<" ">> delimiters are used everything inside, no matter how deeply nested, is also referentially opaque, which keeps things composable.
>>> 
>>> Just asking because I saw Thomas' email about the topic.
>>> 
>>> Regards
>>> Anthony
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
> 





--

Fabio Vitali                            Tiger got to hunt, bird got to fly,
Dept. of Computer Science        Man got to sit and wonder "Why, why, why?'
Univ. of Bologna  ITALY               Tiger got to sleep, bird got to land,
phone:  +39 051 2094872              Man got to tell himself he understand.
e-mail: fabio@cs.unibo.it         Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.unibo.it/

Received on Friday, 11 February 2022 01:18:41 UTC