- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Wed, 14 Dec 2022 21:20:40 +0100
- To: Thomas Lörtsch <tl@rat.io>
- Cc: Souripriya Das <souripriya.das@oracle.com>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <bbc6de04-cfb4-35a6-c4ae-6033358f2e1f@w3.org>
Thomas, note that my argument was not so much about paradoxes, than about self-referential statements (which can be paradoxical or not, but lead to a nasty class of paradoxes). That being said: On 13/12/2022 14:25, Thomas Lörtsch wrote: > How about > > :A a :Lie . > << :A a :Lie >> owl:sameAs :Aq . > :Aq a :Lie . This example is not self-referential, but could be made self-referential :A a :Lie. << :A a :Lie >> owl:sameAs :A. So I stand corrected: RDF-star is just as exposed to this kind of paradox as RDFn. Note, however, that this is not a paradox until you define the semantics of owl:sameAs (which is not part of RDF-star's base semantics) and of :Lie. I believe it would be possible to define the semantics of :Lie in a way that would not blow up in our face in the case above -- but I would have to think about it a bit longer. > Doesn’t that overcome RDF-star's syntactic safe guard against paradoxes? And if it does - I’m not a logician, so I’m not sure - aren’t the consequences even worse for RDF-star than for RDFn, as the paradox targets all occurrences of type << :A a :Lie >>, not only one instance as in RDFn’s case. Not, it does not targets all occurrences, because the occurrences are /distinct/ from the type -- or, as you phrase it in terms of the type-token distinction: the tokens are distinct from the types. That's why it's called type-token /distinction/. :-) pa > > I haven’t fully understood how the RDF 1.x semantics tackles this topic [0] but as I said before my intuition is that going the way of occurrences (which in my understanding is a more generic term for both instances and subtypes, which - see OWL punning - are rather application specific categories) opens the same venue: interpreting a statement as a concrete occurrence of the type instead of as the type itself (as the RDF-star semantics proposes) separates the two, puts the occurrence in the extension of the type, and thereby avoids paradoxes in the semantics already. > > Thomas > > > [0]https://www.w3.org/TR/rdf-mt/#technote > > >> On 9. Dec 2022, at 08:15, Pierre-Antoine Champin<pierre-antoine@w3.org> wrote: >> >> Thanks Souri, >> >> I added a link to the slides in the minutes of the call where you presented them. >> https://www.w3.org/2022/11/17-rdf-star-minutes.html >> >> A few remarks about slides 8 and 9: >> - what you call semantics in these slides is more related to the RDF abtract syntax [1] than the RDF semantics [2]. The former is about structural elements of RDF (IRIs, triples...) while the second is about the "things in the world" that the RDF graph is about. >> >> - In those slides, I see no constraint about preventing triples to talk about themselves (which the CG report explicitly forbids [3]). This allows for something like >> >> :t1 a :Lie (:t1). >> >> or, even more tricky to detect >> >> :t2 a :Truth (:t1). >> :t1 a :Lie (:t2). >> >> This kind of paradoxes may be tricky to model in terms of semantics.... >> >> pa >> >> [1]https://www.w3.org/TR/rdf11-concepts/ >> [2]https://www.w3.org/TR/rdf11-mt/ >> [3]https://www.w3.org/2021/12/rdf-star.html#concepts "Note also that, by definition, an RDF-star triple cannot contain itself" >> >> On 03/12/2022 00:21, Souripriya Das wrote: >>> Attached a revised version of the RDFn slide deck [1] that includes >>> • (slide 8) new slide titled "RDFn Semantics: Essentials, in a few words" >>> • (slide 9) corrected slide titled "RDFn Semantics: Essentials Beyond RDF" that now states that TI INTERSECT TE need not be an empty set and shows the corrected diagram >>> • (slide 14) new slide titled "Enabling Explicit Naming in RDF-star, Serializations, and SPARQL-star" >>> Thanks, >>> Souri. >>> >>> [1]https://lists.w3.org/Archives/Public/public-rdf-star-wg/2022Nov/att-0016/RDFn_WG_Slides.pdf >> <OpenPGP_0x9D1EDAEEEF98D438.asc> >
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Wednesday, 14 December 2022 20:20:47 UTC