W3C home > Mailing lists > Public > www-rdf-logic@w3.org > April 2001

Re: semantics status of RDF(S)

From: <jos.deroo.jd@belgium.agfa.com>
Date: Sat, 7 Apr 2001 02:30:17 +0100
To: phayes@ai.uwf.edu
Cc: aswartz@swartzfam.com, www-rdf-logic@w3.org
Message-Id: <OF5CCACD88.5066EB70-ON41256A27.00070D7E@bayer-ag.com>

>Asserting a negation is more than simply not asserting the negated
>proposition: it is DENYING it. So if RDF supported negation, then an
>RDF processor should draw a conclusion from finding P and the
>negation of P: it ought to notice that they are contradictory. The
>central point, however, is that an RDF triple is supposed to assert
>that a relation holds; and negation is not a relation. So if it is
>encoded as an RDF relation, something needs to 'know' that this
>particular usage isnt meant to be taken literally in RDF, but is
>simply a usage of the RDF datamodel to encode something else. And
>indeed RDF, like any other system of linked arcs which allows one to
>build arbitrarily complex labelled graphs, can be used to encode (the
>syntax of) other languages in this way. But that isnt using RDF to
>express negation: it is using RDF datastructures to encode the syntax
>of some other language which expresses negation.

I'm used to think about ~p (negation of p) as p->false
(the relation 'p implies false').
So if we assert p->false (to be true) then p is false
and if we found p->false to be false then p is true.

When using resolution one cannot have such p->false rules.
So one cannot (as such) deny the fact that p is true.

There is however an easier problem (maybe).
On the proof level (where proof expressions live)
we can discover that p has a no-proof-found value.
Of course that is not the denial of p but that
is not a problem for a proof expressions's life!
All it has to express is evidence that can be
syntactically checked to give semantic validity
(and such expressions can contain p->false
parts coming from negated premisses).

Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
Received on Friday, 6 April 2001 20:42:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:20 UTC