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

Re: questions on assertion

From: pat hayes <phayes@ai.uwf.edu>
Date: Tue, 9 Jul 2002 11:57:00 -0700
Message-Id: <p05111b2db950df2a52ca@[]>
To: "Giles Hogben" <giles.hogben@jrc.it>
Cc: www-rdf-logic@w3.org

>I am confused about the meaning of assertion as used in the RDF model theory
>spec and would appreciate some clarification:
>Looking at the following phrase in the model spec,
>"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
>I looked for a definition of what you take assertion to mean and I couldn't
>find anything in the w3 RDF site which fitted in this context (or others in
>which the term is used in the document) and nothing specifically within the
>model document at all.

Sigh. I guess at some point one just has to appeal to English. I 
meant it only in the usual, informal, sense in which to make an 
assertion is to claim that some sentence is true (usually by uttering 
the sentence in an appropriate context, as when I say "It's starting 
to rain", meaning to refer to the geographical region I am located in 
at the time of speaking.)

>On the absence of a formal definition of how the noun "assertion" is used, I
>would take to mean that the triples are asserted by the author of the rdf
>store to be true, which is the standard use of the term

Right, exactly.

>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
>2. X is statement 1.
>3. X is not true.
>4. my car has four wheels
>5. Y is statement 4.
>6. X is an assertion made by P
>7. Y is an assertion made by Q
>It seems to me that there are problems with expressing these statements in
>RDF,  given the assumptions regarding assertion - mainly.
>1. If we interpret an assertion to mean "I believe 'my car is red' is true."
>then how do we interpret 3.

Well, you can't say "not" in RDF. If you could, then 1. and 3. would 
contradict one another.

>Surely this is saying:
>If  "my car is red" in rdf carries an implicit assertive meaning, then  it
>is saying:
>"I believe 'my car is red' is true"
>But then 3. is saying:
>"I believe ["I believe 'my car is red' is true"] is false"
>Which is a paradox.

No, at worst it would just be a contradiction. In fact, as it stands 
it's not even a contradiction: its just a rather elaborate way of 
saying that I don't believe that I believe that my car is red. If you 
add that to 1. you get a contradiction, of course.

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

Well, if RDF were to allow negations, one would simply assert the 
negation, eg assert 3. without asserting 1.

It may be that you are referring to a purely syntactic problem, which 
is how to encode expressions which are syntactically more complex 
than single triples in an RDF graph, without 'accidentally' asserting 
the subexpressions. That is indeed a problem, and the appropriate 
answer, in my view, is that we should extend RDF syntax to allow 
them. This is a controversial issue, however: for more on the topic, 
see the discussions of 'layering' in the Webont archives.

>This is in my view a real problem for applications involved in reputation
>and trust.
>2. If rdf statements implicitly carry assertion, how can I specify the
>author of the assertion?

Right now, about the only way to do it is by using reification, but 
that doesn't seem (to me) to be a viable long-term solution. I (and 
many others) agree that we need better ways to do this kind of 
'tagging' of assertions with provenance information: again, the topic 
has been discussed at various times in the Webont archives.

Pat Hayes

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 9 July 2002 14:56:47 UTC

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