W3C home > Mailing lists > Public > www-rdf-logic@w3.org > July 2002

RE: questions on assertion

From: Joshua Allen <joshuaa@microsoft.com>
Date: Mon, 8 Jul 2002 23:10:46 -0700
Message-ID: <4F4182C71C1FDD4BA0937A7EB7B8B4C1020ED494@red-msg-08.redmond.corp.microsoft.com>
To: "Jonathan Borden" <jonathan@openhealth.org>, "Giles Hogben" <giles.hogben@jrc.it>, <www-rdf-logic@w3.org>

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>
-----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 
Subject: Re: questions on assertion

	> > 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
	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/
	<#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>
	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'
Received on Tuesday, 9 July 2002 02:11:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:38 UTC