Re: Referential transparency and opacity

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

Because "connectedTo" is symmetric, how do you know which elevation to
subtract from which? That's why I think "elevationDifferenceInM", and an
absolute value, would be a slightly more correct way of doing it, and then
the inference would still hold.

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

Happy to look at an example, but I think this will have a related problem:
even if the relation is asymmetric this time, how is the direction being
decided?

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

1) If "creation time" is really the thing you want to express then this is
really talking about occurrences of those triples, and the modeling would
be different and utilize the proposed "occurrenceOf" relation.

If the reason to record the creation time is to express "temporal
validity", then statement-level timestamping using time and space positions
is, once again in my view, the broader solution here:

<#location1> :connectedTo <#location2> [2022-02-11T16:05:01Z, _) .
<#location2> :connectedTo <#location1> [2022-02-11T16:05:03Z, _) .

2) Can you give an example please?

In any case, I agree with Fabio that one solution probably doesn't need to
be forced onto everybody.

Regards
Anthony

On Sat, Feb 12, 2022 at 1:36 AM Pierre-Antoine Champin <
pierre-antoine.champin@ercim.eu> wrote:

>
> On 11/02/2022 01:26, Anthony Moretti wrote:
>
> Thomas has basically understood the rationale behind the syntax exactly.
>
> In GitHub Pierre-Antoine commented
> <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
>>
>