Re: Referential transparency and opacity

> Am 12.02.2022 um 01:59 schrieb Anthony Moretti <anthony.moretti@gmail.com>:
> 
>> I am not convinced that there exist an absolute clear-cut boundary between metadata and additional data

I’m convinced that in general there doesn’t exist such a boundary.

> I'm interested to know what the most ambiguous examples are, if people have any please suggest them.

Provenance is probably a good example. The source of some information might be a dusty, administrative housekeeping piece of data in one case or it might make all the difference in another scenario. 

In general I think it depends more on the information desire of the user than on the data itself and those desires are hard to predict and may be subject to change. Marketing might come up with a new approach and mine for aspects that weren’t considered important (and therefore relegated to "just meta annotations") before. Data from an application context with very specific ways to use and interpret the data might be transferred into a bigger context, e.g. a well understood recipe site with a highly optimized model might transform into a social platform with all kinds of stuff going on and in need of much more flexble modelling schemata. Etc.  

> One of us has to be wrong on this it seems,

With semantics, more often than not nobody/everybody is...

Best,
Thomas

> I'm happy to explore it further.

> Regards
> Anthony
> 
> 
> On Sat, Feb 12, 2022 at 10:59 AM Anthony Moretti <anthony.moretti@gmail.com> wrote:
> 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:
>> [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

Received on Monday, 14 February 2022 11:33:28 UTC