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

RE: questions on assertion

From: Joshua Allen <joshuaa@microsoft.com>
Date: Mon, 8 Jul 2002 15:39:16 -0700
Message-ID: <4F4182C71C1FDD4BA0937A7EB7B8B4C105BA274D@red-msg-08.redmond.corp.microsoft.com>
To: "Giles Hogben" <giles.hogben@jrc.it>, <www-rdf-interest@w3.org>, <www-rdf-logic@w3.org>

> 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">

> 3. X is not true.

<rdf:Description rdf:about="#Statement1" rdf:ID="Statement3">

> 4. my car has four wheels

<rdf:Description rdf:about="urn:autos:my-car" rdf:ID="Statement4">

> 6. X is an assertion made by P

<rdf:Description rdf:about="#Statement1" rdf:ID="Statement6">

> 7. Y is an assertion made by Q

<rdf:Description rdf:about="#Statement4" rdf:ID="Statement7">

> 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))

> So the problem I am getting at, is how can say, without creating a
> inconsistency, that one believes a statement in rdf data is false?

Just because you have two conflicting assertions does not mean that you
have chosen to believe either one of them.

> This is in my view a real problem for applications involved in
> and trust.

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.  Else, if *you*
happen to be person P, you can disregard R and put a ding against him in
your reputation database.  And if P and R turn out to be the same
person, you can just discard both assertions, since they are coming from
a schizophrenic (or you could choose to take the most recent one,
assuming the guy changed his mind or repainted the car).

> 2. If rdf statements implicitly carry assertion, how can I specify the
> author of the assertion? That is - does the assertion implied by 1.

As I showed in 6 and 7, and assuming your subsystem can assert 9-14 for

Also, note that it is not necessary to decorate every assertion like
this.  You could wrap assertions in collections -- this is how Klyne
Contexts work.
Received on Monday, 8 July 2002 18:39:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:41 UTC