- 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
[...] >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