RE: questions on assertion

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

Received on Tuesday, 9 July 2002 02:11:43 UTC