Re: Referential transparency and opacity

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

Cheers Thomas, it's good to get your point of view.

Provenance is probably a good example.
>

So funny, because to me provenance is a good example of my point of view,
haha. If we all vary wildly on this, I think I might try to put my thoughts
in another thread to have a separate discussion there.

Quoting the quote from your second email, I assume it was meant for the
list:

"There is no useful distinction between the representational needs of data
> and metadata." - MCF - Guha, Bray - 6.6.1997 -
> https://www.w3.org/TR/NOTE-MCF-XML-970624/
>

Nice that you found other material about it. To me that quote means triples
can be used for both types, which I agree with, but I don't think it
addresses triples being applied to other triples, which is what RDF-star is
doing.

Anyway, on the original topic, does anybody else have thoughts about
supporting both referential transparency and referential opacity, rather
than just one of them?

Regards
Anthony


On Mon, Feb 14, 2022 at 10:03 PM thomas lörtsch <tl@rat.io> wrote:

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