Re: Referential transparency and opacity

> 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>