Re: questions on assertion

On Tue, 9 Jul 2002, Giles Hogben wrote:

>
>But what about this sentence in the RDF model spec (also in the latest
>draft)?
>
>"This document describes a model theory for RDF(S) which treats the language
>as simple assertional language, in which each triple makes a distinct
>assertion and the meaning of any triple is not changed by adding other
>triples"
>
>An assertion is traditionally a statement that you believe something to be
>true.

No, an assertion is something that is stated as if it were true. An important
tool in checking proofs and dealing with logic is the ability to make an
assertion and not believe it.

What RDF gives is the ability to make asertions. If there are contradictions
between two assertions in a system then the rules of the system have been
violated. It may be that they can be satisfied by wrapping the assertions in
further assertions, it may be that you have found the elegant proof of
Fermat's theorem by contradiction.

The EARL vocabulary is expected to be used in cases where the assertor
probably believes their assertion, but where the use case expects that some
assertions will be true and others will be false -
http://www.w3.org/2001/03/earl - and therefore makes it clear what is an
assertion that we expect to believe (fred said something) and what is an
assertion we expect to be contradicted ([whatever it was that fred said]).

Cheers

Charles

>
>> You are right about the incorrect syntax, thanks.  Also, I agree that
>"veracity" is something outside of RDF, just like "color".  The point being
>that "veracity" is something to be asserted, judged, and weighed; and a
>web-based system must be able to accept or reject assertions.  Given that, I
>see no problem with the example below -- it is clearly contradictory and
>useless, but I don't see a problem with that -- you will be sure to get lots
>of contradictory and useless assertions mixed in with the good stuff in any
>web-based system.  (But maybe I am missing some things?)
>>
>> <rdf:Description rdf:about="#Statement1">
>>     <ex:Veracity rdf:ID="Statement1">False</ex:Veracity>
>> </rdf:Description>
>>
>>
>> -----Original Message-----
>> From: Jonathan Borden [mailto:jonathan@openhealth.org]
>> Sent: Mon 7/8/2002 9:15 PM
>> To: Joshua Allen; Giles Hogben; www-rdf-logic@w3.org
>> Cc:
>> Subject: Re: questions on assertion
>>
>>
>>
>> Joshua,
>>
>> >
>> > > In this case, I am trying to figure out in that case how the RDF model
>> > > theory would cope with expressing the following.
>> > >
>> > > 1. my car is red
>> >
>> > <rdf:Description rdf:about="urn:autos:my-car" rdf:ID="Statement1">
>> >   <ex:Color>Red</ex:Color>
>> > </rdf:Description>
>>
>> This isn't quite legal RDF syntax, you cannot have both an rdf:about and
>> rdf:ID on the same description. Perhaps you want to add the rdf:ID to the
>> property?
>>
>> In any case the triple:
>>
>> Statement1: <urn:autos:my-car> ex:Color "Red" .
>>
>>
>> >
>> >
>> > > 3. X is not true.
>> >
>> > <rdf:Description rdf:about="#Statement1" rdf:ID="Statement3">
>> >   <ex:Veracity>False</ex:Veracity>
>> > </rdf:Description>
>>
>> RDF does not provide/allow negation by design. The above is not the same
>as
>> "X is not true" because "truth" is defined according to the RDF model
>> theory -- see: http://www.w3.org/TR/rdf-mt/
>>
>> i.e.
>>
>> <#Statement1> ex:Veracity "False" .
>>
>> Does not have anything to do with _falsehood_ according to the RDF model
>> theory. You may have your own model theory which might use RDF triples as
>> syntax, and then you might assign your own truth value to the triple, but
>> that isn't according to RDF. For example suppose we take what you say at
>> face value:
>>
>> <rdf:Description rdf:about="#Statement1">
>>     <ex:Veracity rdf:ID="Statement1">False</ex:Veracity>
>> </rdf:Description>
>>
>> Is Statement1 true or false? well if it is true then it is false, and if
>it
>> is false then it is true, ... and if we have paradoxes then we can prove
>> anything, which would not make for very useful inferences.
>>
>>
>> >
>> > > 6. X is an assertion made by P
>> >
>> > <rdf:Description rdf:about="#Statement1" rdf:ID="Statement6">
>> >   <dc:Author>P</dc:Author>
>> > </rdf:Description>
>>
>> Close enough (sort of). This _was_ the intention of the current RDF REC,
>but
>> again, according to http://www.w3.org/TR/rdf-mt/ this remains unclear.
>>
>> >
>> > > 7. Y is an assertion made by Q
>> >
>> > <rdf:Description rdf:about="#Statement4" rdf:ID="Statement7">
>> >   <dc:Author>Q</dc:Author>
>> > </rdf:Description>
>> >
>> > > 1. If we interpret an assertion to mean "I believe 'my car is red' is
>> > > true."
>> >
>> > More like "Someone asserted that ('my car is red' is true)".
>> >
>> > > "I believe ["I believe 'my car is red' is true"] is false"
>> > > Which is a paradox.
>> >
>> > Someone asserted that (asserting ('my car is red' is true) is false))
>>
>> In the absense of negation, RDF avoids this paradox.
>>
>> ...
>> >
>> > Actually, I think that trust in metadata depends on people being able to
>> > make statements like number 3.  This is exactly what is needed to allow
>> > you to choose what assertions to trust.  For example, assume that your
>> > list has a few more assertions:
>> >
>> > 8. Statement 3 is an assertion made by R
>> > 9. Statement 6 is true
>> > 10. Statement 7 is false
>> > 11. Statement 8 is true
>> > 12. Statement 9 is made by your tamper-proof digital signature checker
>> > 13. Statement 10 is made by your tamper-proof digital signature checker
>> > 14. Statement 11 is made by your tamper-proof digital signature checker
>> >
>> > Now, if you can determine that R is someone you routinely trust, you can
>> > discard assertion #1, and store some internal information about person P
>> > so that you know to be suspicious of him in the future.
>>
>> ... this is all sensible, but outside of RDF, i.e. RDF does not itself
>> address the issues of 'belief' and 'trust'
>>
>> Jonathan
>>
>>
>>
>>
>

-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI  fax: +33 4 92 38 78 22
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Tuesday, 9 July 2002 22:35:27 UTC