Re: Referential transparency and opacity

On 11/02/2022 01:26, Anthony Moretti wrote:
> Thomas has basically understood the rationale behind the syntax exactly.
>
> In GitHub Pierre-Antoinecommented 
> <https://github.com/w3c/rdf-star/issues/200#issuecomment-1035011800>:
>
>     [about the inference rule with|ow:inverseOf|]
>     Another example showing that you do not always want to do that:
>
>     |<#location1> :connectedTo <#location2> {| :distanceInKm 12;
>     :elevationGainInM 15 |}. :connectedTo a owl:SymmetricProperty. #
>     equivalent to :connectedTo owl:inverseOf :connectedTo . |
>
>     While the rule above makes sense for|:distanceInKm|, it clearly
>     does not for|:elevationGainInM|...
>
>
> Is there another example where it shouldn't hold? Just because I think 
> ":elevationGainInM" is probably better modeled as 
> ":elevationDifferenceInM".

Not sure how different that would be. Note that the "gain" can be 
negative, in my view, so you might as well rename it to "difference" if 
that's clearer.

My point was: if the difference between loc1 and loc2 is 15, then the 
difference between loc2 and loc1 is -15. Although they are still 
correlated, they are not the same and so the proposed inference rule is 
not appropriate.

We could even imagine other properties were no such correlation would 
exist. E.g.: some roads have different speed limit depending on the 
direction.

> Also, is there an example where the annotation is metadata and not 
> additional data? I think the lack of separation there is still a 
> problem in all of this.
I am not convinced that there exist an absolute clear-cut boundary 
between metadata and additional data -- but the following examples 
should qualify as metadata well enough.

1) Consider the creation date of a triple.

We might have

<< <#location1> :connectedTo <#location2> >> dc:created 
"2022-02-11T16:05:01Z"^^xsd:dateTimestamp.
<< <#location2> :connectedTo <#location1> >> dc:created 
"2022-02-11T16:05:03Z"^^xsd:dateTimestamp.

because the first one was added manulally, and the second one was 
derived an instant later by the inference engine.

2) The inference engine might also add a "derivedFrom" relationship from 
the reverse triple to the original one (which, arguably, should not be 
"inherited" by the original triple).

   pa
>
> Regards
> Anthony
>
> On Fri, Feb 11, 2022 at 2:33 AM thomas lörtsch <tl@rat.io> wrote:
>
>     One more thing:
>
>     > 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>
>     >>> :
>
>     </snip>
>
>     >> - << … >> 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*.
>
>
>     How am I to interpret section "6.1 Mapping RDF-star abstract
>     syntax to RDF" of the CG report [0] where the unstar-mapping maps
>     an embedded triple to a freshy minted blank node with certain
>     properties?
>
>     And section "6.4.6 Other alternatives to referential opacity" [1]
>     where a mapping with fully referentially transparent semantics is
>     defined that looks very, very much like standard reification and
>     differs from the proposed semantics only in that it omits
>     referential opacity?
>
>     I’d say the blank nodes b that both mappings freshly mint
>     represent occurrences. So is the mapping wrong or is the semantics
>     broken?
>
>     Thomas
>
>
>
>     [0] https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#mapping

>     [1]
>     https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#other-alternatives-to-referential-opacity

>