W3C home > Mailing lists > Public > www-webont-wg@w3.org > May 2002

RE: DTTF: summary (gasp!)

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 22 May 2002 14:02:43 +0100
To: "Jonathan Borden" <jonathan@openhealth.org>, "WebOnt WG" <www-webont-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDIEAECEAA.jjc@hplb.hpl.hp.com>
On any vote concerning this summary, I would formally abstain.
This is merely because I see the preamble (i.e. most of the message) as
overstating the case.
But I acknowledge that there is *a* case and so support the conclusion.


  -----Original Message-----
  From: www-webont-wg-request@w3.org [mailto:www-webont-wg-request@w3.org]On
Behalf Of Jonathan Borden
  Sent: 22 May 2002 06:11
  To: WebOnt WG
  Subject: DTTF: summary (gasp!)

  The WebOnt WG has been debating the issues surrounding the layering of OWL
onto RDF for the existence of the WG with seemingly no end. At its core, the
issue regards the ability to create a new language on top of an existing
language in which everything which is said, is said to be a truth, the new
language looses its ability to add anything to the equation or worse
paradoxes ensue.

  Note: this is long, to cut to the chase skip to the end. This document is
also at: http://www.openhealth.org/WOWG/DTTF

  The effort to both develop OWL as an extension to RDF and assert each and
every triple, appears to have been akin to an attempt to stuff a balloon
filled with water into a cube whose volume is less than that of the balloon:
every attempt to stuff the balloon in results in some part of the balloon
squeezing itself out somewhere.

  The effort to summarize this discussion has been difficult, in a large
part to the the unfortunate lack of proper _Subject_ lines to our email
discussions. In any case:

  The Problem: Peter Patel-Schneider has provided multiple and lengthly
discourses on the paradoxes that ensue as a result of OWL as a  "same
syntax" extension of RDF.


  The problem seems to be a result of the requirement for:

  1) all RDF triples to be asserted i.e. "truths"

  2) classes as instances

  3) OWL's need to support commonsense entailments e.g.
intersectionOf(student,employee) <=> intersectionOf(employee,student)





  > _:1 fowl:onProperty rdf:type .
  > _:1 fowl:hasClass _:2 .
  > _:2 fowl:OneOf _:3 .
  > _:3 fowl:first _:4 .
  > _:3 fowl:rest fowl:nil .
  > _:4 fowl:complementOf _:1 .
  >   _:1 is the set of objects
  >   that are related to a particular complement of _:1
  >   via rdf:type
  >   if x rdf:type _:1
  >   then x rdf:type _:4
  >   but _:1 and _:4 are complements
  >   so not x rdf:type _:1
  >   if not x rdf:type _:1
  >   then x rdf:type _:4
  >   because _:1 and _:4 are complements
  >   but then x rdf:type _:1

  Pat Hayes states the problem such paradoxes cause for the Semantic Web:


  Look, the paradoxes are not a programming problem, and they don't have
anything to do with non-termination. (A non-terminating process corresponds
to something that is undecideable, roughly, not to a paradox.) If the SW
tried to do reasoning in the presence of paradoxes, the problem would not be
that code fails to terminate. All the reasoning engines would work fine, and
if they were using DL-style logic then they would probably work quite
efficiently and rapidly, producing correct, checkable proofs using
semantically correct inference rules. However, the conclusions would all be
worthless, because that perfectly valid logic would be able to prove that
2+2=5 and the Pope was both a Roman Catholic and also not a Roman Catholic,
and so on. The problem would not be in the code, but in the content of the
expressions manipulated by the code. The correctness of the code would not
guarantee that the conclusions made any sense (in fact, it would guarantee
that they *didnt* make sense.) The conclusions produced by any reasoner are
only as good as the information it is given. In the presence of paradoxes it
can produce nonsense all by itself, so any information it handles is
potentially corrupted.


  Such problems illustrate the subtleties which result from simple
assertions as simple "truthes" e.g. from Peter F. Patel-Schneider


  Now what about a document that consists of the following single statement:

           this a n3:falsehood .

  Consider any interpretation for the document. Suppose the statement is
  true in the interpretation.  But then the statement is false, because the
  entire document belongs to n3:falsehood, and the statement is the only
  statement in the document.  Suppose the statement is false in the
  interpretation.  But then it is true, because the entire document does not
  belong to n3:falsehood and the statement is the only statement in the
  document.  Thus it is impossible to assign a truth value to this
  statement (and document), thinking model theoretically, or it is possible
  to derive both this formula and its negation, thinking proof

  (The document is, of course, just the liar's paradox in another guise. If
  anyone is uncomfortable with the use of an implicit scope for ``this'',

         { this a n3:falsehood } a log:Truth .

  under a reading that log:Truth is contingent truth would have done just as





  Tarski's "Liar's paradox" led to his stating:


       If we now analyze the assumptions which lead to the antinomy of the
  liar, we notice the following:

  We have implicitly assumed that the language in which the antinomy is
  constructed contains, in addition to its expressions, also the names of
  these expressions, as well as semantic terms such as the term "true"
  referring to sentences of this language; we have also assumed that all
  sentences which determine the adequate usage of this term can be asserted
  the language. A language with these properties will be called

  We have assumed that in this language the ordinary laws of logic hold.
  -- http://www.ditext.com/tarski/tarski.html

  And so the problem of such paradoxes may be intrinsic to attempts to
"layer" languages on top of languages which are "semantically closed" such
as RDF sans unasserted triples.


  The provision for triples that are unasserted allows such triples to be
employed by OWL for purely syntactic purposes e.g.


       <List><first><Class rdf:resource="#student"/></first>

            <rest><List><first><Class rdf:resource="#employee"/></first>






  can be defined to entail =>


       <List><first><Class rdf:resource="#employee"/></first>

            <rest><List><first><Class rdf:resource="#student"/></first>






  i.e. owl:List, owl:first, owl:rest are used for syntactic purposes by OWL,
whose MT defines the equivalence of the expressions regardless of the
"truth" about which is first etc.

  Similarly expressions such as:

  this owl:include <http://example.org/anOntology.owl> .

  are used as syntactic extensions to RDF, and result in committment to the
referenced ontology.

  The real requirement for unasserted triples comes down to the real
inability of a language to extend itself:


  This idea of a self-extending language that can, in
  principle, describe extensions to itself and then in some sense
  become those extensions, like a railway locomotive laying its own
  tracks ahead of itself, is a powerful vision, and one that I can see
  might excite considerable enthusiasm.  However, so is a
  perpetual-motion machine, and for much the same reasons.



  "Comprehensive entailments" (CE) had been proposed as a "way out of the
dark" i.e. a solution wich does not involve unasserted triples:



  This proposal appears to have problems with paradoxes:


  From a theoretical perspective Godel's Proof raises concerns as to the
viability of such an approach (e.g. substitute "CE" for "PM"). In any case,
given the raised paradox, such an approach would appear to require a
considerable degree of additional research which is not appropriate to the
charter of the WG.

  Implementing "unasserted triples" in RDF.

  The RDF MT as it stands is entirely compatible with triples that are not
asserted. A mechanism is needed to label such triples. There are several

  1) a syntactic device such as contexts e.g. embedded <rdf:RDF> or
<rdf:context> or <rdf:dark>

  ****2) an RDFS based device such as

  -- this is my preference and would (IMHO) require the least change to RDF

Received on Wednesday, 22 May 2002 09:02:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:30 UTC