on paradoxes - was Re: "Multi-Edge Support in RDFn" slides

There are many different flavours of paradoxes.


Consider the barber paradox:

The barber shaves all and only those who do not shave themselves.  Does the 
barber shave himself?  This doesn't make sense and is thus a paradox.


What is going wrong here?   Suppose we write the premise in first-order logic:

( A x  b shaves x <-> x ~shaves x )

This is a contradiction - there is no interpretation where it is true.

In these interpretations is the conclusion true?  Given that there are none, 
then yes.  But also, given that there are none, the conclusion is also false 
in all of them.

So the problem is that in first-order logic reasoning from contradictions 
doesn't match our intuitions.  But this doesn't produce any catastrophes in 
the machinery of first-order logic.


But suppose we want to answer a related question in an early form of set 
theory.  (Actually this is in an early form of set based on a modern 
underlying logic.)  In this set theory any set that can be defined by a 
first-order formula with one free variable exists in all interpretations and 
membership in it is supposed to be well defined, i.e., in any interpretation 
every domain element either satisfies the formula or does not satisfy the 
formula but not both.

Consider the set { y : y ~shaves y & ( A x  b shaves x <-> x ~shaves x ) }.  
This set is defined by a first-order formula so it exists in all 
interpretations.  But is b in the set or not?  If b is in the set then it 
cannot be in the set. Likewise if b is not in the set then it has to be in the 
set. So there are no interpretations with this set.  But this set exists in 
all interpretations so there are no interpretations.

And here is a real paradox - a complete breakdown of the semantics for this 
form of set theory.  The solution to the paradox was to limit the power of set 
constructors.



As far as I can tell, there is no requirement in RDF-star that embedded 
triples exist in all interpretations.  So even if there are embedded triples 
that cannot be in any RDF interpretation this does not cause a complete 
breakdown of the semantics for RDF-star.

So even if RDF-star was strong enough to capture the liar's paradox this would 
only mean that an RDF-star graph containing the liar's paradox would be a 
graph with no interpretations, just like an RDF graph containing the literal 
"x"^^xsd:integer has no D-interpretations if D contains the datatype 
xsd:integer with its normal meaning.


peter


On 12/16/22 09:39, Thomas Lörtsch wrote:
>
>> On 16. Dec 2022, at 12:58, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
>>
>> On 14/12/2022 23:23, Thomas Lörtsch wrote:
>>>> On 14. Dec 2022, at 21:20, Pierre-Antoine Champin <pierre-antoine@w3.org>
>>>>   wrote:
>>>>> 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 distinctfrom 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. :-)
>> Sorry, I didn't quite finish editing that sentence. What I meant was :
>>
>> No, it does not targets all occurrences, because the occurrences are distinct from the triple -- 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. :-)
>>> The quoted triple << :A a :Lie >> is by the CG report defined to be a type
>> No, the CG report does not use the term "type" in the definition. It mentions the type-token distinction as an analogy.
>>
>> A quoted triple is a term (https://www.w3.org/2021/12/rdf-star.html#dfn-rdf-star-terms) alongside IRIs, literals and blank nodes
>>
>>>   that means the same everywhere.
>> just like an IRI, a literal or a blank node means the same everywhere (mind you, I'm talking about blank nodes, not blank node identifiers, who have a local scope).
>>>   So everything that is asserted about it is asserted about that type everywhere it is used as term in an assertion (to avoid saying "everywhere it occurs").
>> rephrasing (to avoid "type" and "occurs"): every statement (asserted triple) containing this term makes an assertion about the thing denoted by this term (which is the same for all statements/assertions). Yes.
> Okay. Your wording is more precise than mine, but the essence in this context is that the quoted triple means the same everywhere. That’s what I wanted to express by calling it a type.
>
>>> An occurrence OTOH, as described by RDFn or RDF standard reification or by :X in
>>>     << :A a :Lie >> :hasOccurrence :X
>>> occurs only once.
>>>
>> Not sure what you mean by that: "An occurrence (...) occurs only once"
>>
>> When we talk about an occurrence, it is not the occurrences that occurs! When we talk about the occurrences of a word in a phrase, its is the words that occur, not the occurrences... Same when we are talking about the occurrences of a term in an RDF(-star) graph.
> Okay, trying to re-word my argument…
>
> An annotation on an RDF-star quoted triple annotates the triple itself, everywhere is occurs.
>
> When an occurrence is defined, like in:
>      _:x1 :occurrenceOf <<a b c>> .
> and that occurrence is annotated, like in:
>      _:x1 e f .
> then the annotation annotates that occurrence, identified by _:x1, not the quoted triple <<a b c>> .
>
> If that occurrence is to be understood as an instance or a subtype of the quoted triple or if it is to be understood in another relation to the quoted triple or if the nature of that relation should not be defined at all is a discussion that we will have to have. For now it seems enough to state that there is a difference between the two.
>
> That occurrence is in this example identified by _:x1 and that identifier can indeed be used - or "occur" - many times. It always identifies one and the same occurrence, but using it in a new statement to identify and annotate the occurrence creates an occurrence of the occurrence… what can I do - that’s just how meta-modelling works if it is applied recursively. I have no idea how to make the wording easier to comprehend.
>
> Back to the initial topic: introducing a paradox in a quoted triple makes the term itself paradoxical, everywhere it is used. So if <<a b c>> is paradoxical then any occurrence defined on <<a b c>>, like _:x1 above and eventual _:x2, _:x3 etc occurrences will all be paradoxical.
> If on the other hand the syntax doesn’t allow to annotate the term, but only specific occurrences, then the consquences might be less catastrophical. RDFn for example doesn’t provide a means to refer to the statement understood as a term, it refers to a specific occurrence/token/instance. That might be considered an advantage. There are other and IMO more important advantages to RDFn's approach, so I’m already regretting that my remark might have side-tracked the discussion. But paradoxes are not to be taken lightly I’m told.
>
>
> Best,
> Thomas
>
>
>>    pa
>>
>>>   So the paradox would be more "contained". If that makes much of a difference in practice is another question. It seems a little more harmless to me, but a reasoner might be just as upset either way.
>>>
>>>
>>> Thomas
>>>
>>>
>>>
>>>>    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>
>>>>>>
>>>>>>
>>>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>>>>
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>

Received on Friday, 16 December 2022 17:09:00 UTC