Re: Referential transparency and opacity

> Am 10.02.2022 um 15:43 schrieb Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>:
> 
> 
> 
> 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...).

It is certainly a burden that according to the CG report I have to declare for each property in each graph its referential-transparency inducing powers if I want the embedded triple they annotate to be treated as referentially transparent. Only AFTER THAT the way is free to do what you do above. So that is definitely an extra step. I have no idea what owl:imports or "follow your nose" would have to do with it or how you think an example that doesn’t even contain an embedded triple can prove your point.

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

You blur that distinction between triples and occurrences yourself in the example you gave in your recent blog post: there you propose to either annotate the embedded triple directly - as a type, or implicitly treating it as an occurrence - or create an intermediate resource - thereby creating an occurrence.

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

I’d say the pro’s and con’s of types vs occurrences and if the distinction should always made be explicit need more discussion. Also nothing is ever exactly the same but that’s not a problem as the semantics of standard reification isn’t followed to the book in a lot of places. It’s more important to come up with a sound and easy to use solution for embedded triples. As the embedded triple describes its subject without needing to create an identfier there will always be a gap t standard reification which needs some node, blank or not, to attach the reification quadlet to. That’s one reason why I would prefer proper identifiers all the way instead of embedded triples, but we’re arguing to come to an agreement, right?

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

I didn’t claim that all entailments one would wish for are easy to generate from a referentially transparent embedded triple. But owl:sameAs would for example work as expected, so :alice and :Alice would co-denotate. That’s pretty useful. Also subpropreties should work as intended and probably a few more things.

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


You didn’t say anything about the main issue here: why should almost everbody have to dance around a use case that almost nobody persues when there are easy alternatives? Instead you indulge in side-issues that are, frankly, besides the point.

Thomas

>   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>
>>> 
> <OpenPGP_0x9D1EDAEEEF98D438.asc>