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

Re: questions on assertion

From: Jonathan Borden <jonathan@openhealth.org>
Date: Tue, 9 Jul 2002 00:15:36 -0400
Message-ID: <00a201c226ff$4745ade0$0201a8c0@ne.mediaone.net>
To: "Joshua Allen" <joshuaa@microsoft.com>, "Giles Hogben" <giles.hogben@jrc.it>, <www-rdf-logic@w3.org>

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 00:30:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:42 GMT