Re: Referential transparency and opacity

On 10/02/2022 14:38, thomas lörtsch 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?

Yes, you can say that. But this is no different from any other property 
in any other vocabulary.

Consider graph G1:

     <#pa> a foaf:Person.

It does *not* entail G2,

     <#pa> a foaf:Agent.

even though the FOAF ontology (another graph) says:

     foaf:Person rdfs:subClassOf foaf:Agent.

On the other hand, graph G3

     <#pa> a foaf:Person.
     foaf:Person rdfs:subClassOf foaf:Agent.

does entail G2.

That "burden" is not specific to RDF-star or TEPs, and strategies to 
overcome it are well known and implemented (owl:imports, follow your 
nose...).

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

Do you mean by that << S P O >> would be just another way of writing [ 
rdf:subject S ; rdf:predicate P ; rdf:object O ] ?

Then

   << :s :p :o >> :a :b.
   << :s :p :o >> :c :d.

would be interpreted differently from

   << :s :p :o >> :a :b ; :c :d.

which was /never/ the case in any published version of RDF*. Therefore...
> - <<" … ">> 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
... I challenge that claim.
> - 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

No they would not.
Example from https://github.com/w3c/rdf-star/issues/200.

 From the following graph,

    << :alice :employer :acme >> :since 2021.
     :employer owl:inverseOf :employee.

they want to derive:

    << :acme :employee :alice >> :since 2021.

Even with standard reification, that does not work out of the box. You 
need dedicated rules to support that.

And yes, these rules can be implemented in a system handling quoted 
triples as referentially opaque.

   pa

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