Re: Revisiting RDF-star semantics (was Re: Why is the RDF-star working group standardising RDF 1.2 and SPARQL 1.2?)

This is clear. The CG report does, however, represent many, many discussions and lots of work, and I do not want to lose or redo the work. But the WG can make its own decisions, and this was always clear already when we were drafting the charter. For one, we now have people participating who were not in the CG.

Ora


On 2/1/23, 11:28 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    Consensus in the CG is not consensus in the WG.

    The CG final report is, of course, a starting point but as far as I am
    concerned it is not to be considered to represent any form of consensus in the WG.


    peter



    On 2/1/23 11:00, Doerthe Arndt wrote:
    > Dear Thomas,
    >
    > Of course I remember the discussions and would like to keep this new edition efficient (but of course without ignoring you). So, before we get back to the more contraversial discussion about referential opacity: What is your take on the blank nodes? I guess you would want them to be transparent?  Because here I had the idea that there was a consensus and I would like to start with the few agreements we had.
    >
    > Kind regards,
    > Dörthe
    >
    >> Am 01.02.2023 um 16:32 schrieb Thomas Lörtsch <tl@rat.io>:
    >>
    >> Hi Dörthe,
    >>
    >>> On 1. Feb 2023, at 14:19, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
    >>>
    >>> Dear Peter,
    >>>
    >>> As far as I remember, the desired level of transparency has been discussed at the very beginning of the community group (and not the working group as I erroneously wrote in my last mail). From then on, I have always taken it as a given.
    >> In the very beginning of the community group I didn’t properly understand the question. The more I understood it, the more I criticized the design, culminating in my mail "drop referentially opaque semantics in embedded triples" [0] from May 2021, accompanied by issues on Github and discussions in the CG teleconferences. So, you may have taken it as a given after an initial discussion, but I certainly did not and I was sufficiently vocal about that. Also I believe that when the CG report mentions that no consensus on the semantics could be reached it refers not the least to this discusion.
    >>
    >> Best,
    >> Thomas
    >>
    >>
    >> [0] https://lists.w3.org/Archives/Public/public-rdf-star/2021May/0023.html

    >>
    >>> To the best of my knowledge, the working group has not discussed that matter so far.
    >>>
    >>> Kind regards,
    >>> Dörthe
    >>>
    >>>> Am 31.01.2023 um 15:35 schrieb Peter F. Patel-Schneider <pfpschneider@gmail.com>:
    >>>>
    >>>> Have there been discussions in the working group about the desired level of transparency?
    >>>>
    >>>>
    >>>>
    >>>> peter
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>> On 1/31/23 08:45, Doerthe Arndt wrote:
    >>>>> Dear Antoine,
    >>>>>
    >>>>> We had discussions at the very beginning of the RDF-star working group whether or not blank nodes are to be transparent. If we accept total opacity, your solution would be indeed very nice and - as you said - we could still add a condition to your mapping that two isomorphic rdf-star triples should map to the same resource. I just understood from the previous discussions in this group that we would like to have that:
    >>>>>
    >>>>> << _:a :p :o >> :x :y . _:a :p :o.
    >>>>>
    >>>>> entails
    >>>>>
    >>>>> << _:b :p :o >> :x :y . _:b :p :o.
    >>>>>
    >>>>> and does not entail
    >>>>>
    >>>>> << _:b :p :o >> :x :y . _:a :p :o.
    >>>>>
    >>>>> Is that still the case?
    >>>>>
    >>>>> I think the most critical cases are the ones were we also assert the quoted triple. As Peter mentioned, these blank nodes are what makes this whole modeling complicated (and of course the literals, but that is a separate story).
    >>>>>
    >>>>> Kind regards,
    >>>>> Dörthe
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>> Am 31.01.2023 um 13:45 schrieb Antoine Zimmermann <antoine.zimmermann@emse.fr>:
    >>>>>>
    >>>>>> Le 27/01/2023 à 20:57, Peter F. Patel-Schneider a écrit :
    >>>>>>> This has to be done carefully if blank nodes are to be transparent.
    >>>>>> As described in my previous email, my proposal is to make everything in an embedded triple completely opaque.
    >>>>>>
    >>>>>> Just like:
    >>>>>>
    >>>>>> <http://x.eu/?s=_%3Ab&p=http%3A%2F%2Fx.eu%2Fp&o=%2201%22%5E%5Exsd%3Aint>
    >>>>>>
    >>>>>> could be a way of referring to, or being related to, the triple:
    >>>>>>
    >>>>>> _:b <http://x.eu/p> "01"^^xsd:int .
    >>>>>>
    >>>>>> and a system could extract the parameters of the URI to do interesting things with them, but as the semantics is concerned, there is no a priori relation between the URI and the triple, nor between the URI and the components of the triple.
    >>>>>>
    >>>>>> --AZ
    >>>>>>
    >>>>>>> peter
    >>>>>>> On 1/27/23 13:30, Pierre-Antoine Champin wrote:
    >>>>>>>> On 27/01/2023 11:49, Antoine Zimmermann wrote:
    >>>>>>>>> (*) RDF-star basic semantics would be defined on any RDF-entailment regime by adding a mapping IT from embedded triples to the set of resources IR. Under this basic semantics, embedded triples simply act as distinct names, as if they were IRIs. This does not preclude extensions where the internal structure of the embedded triples makes a difference.
    >>>>>>>> I like that.
    >>>>>>>>
    >>>>>>>> Would you mind developing this further?
    >>>>>>>>
    >>>>>>>>   pa
    >>>>>>>>
    >>>>>>>> PS: also, the https://github.com/w3c/rdf-semantics repo is available for PRs ;-)
    >>>>>>>>
    >>>>>> --
    >>>>>> Antoine Zimmermann
    >>>>>> ISI - Institut Henri Fayol
    >>>>>> École des Mines de Saint-Étienne
    >>>>>> 158 cours Fauriel
    >>>>>> 42023 Saint-Étienne Cedex 2
    >>>>>> France
    >>>>>> Tél:+33(0)4 77 42 66 03
    >>>>>> https://www.emse.fr/~zimmermann/

Received on Wednesday, 1 February 2023 18:34:45 UTC