Re: SUO: Foundations for ontology
John,
There are several issues that I have with what you are proposing.
1. It would be beneficial to have automated tools that compose or even
help develop ontologies. However, these tools do not yet exist. Kestrel
has tools that help to compose highly formal theories in support of
software program synthesis, and it's not even clear how much leverage their
Specware tool has for that task, much less creation of general purpose
ontologies. In the absence of tools that we imagine might help, how should
we proceed? It seems to me that our only choices are not to create any
ontologies at all, or to create them by hand.
2. The lattice of all possible theories idea is interesting but again we
need to know specifically how it would work, with the tools we have
available today. In the DARPA work that I'm familiar with that is
investigating ontology merging, (such as OntoMorph at ISI and Chimera and
Stanford) these is a great deal of human effort needed even in merging
simple taxonomies. It's much easier to adopt a ready-made general ontology
than to try to compose one on the fly.
3. The current SUMO is well delineated into separate theories. Of course,
many sections depend on other previous sections but that would have to be
the case even in a dynamically combined ontology - a theory of agency would
probably have to have access to a theory of time and both would need a
theory of relations. What in practice would have to be done to SUMO (other
than possibly putting the different section into different files) for it to
conform to this recommendation?
4. Fritz had a good response to some criticism of Cyc recently. His
response was essentially that "From the fact that 'Cyc tried X and it
didn't work' one shouldn't conclude that 'X doesn't work' only that Cycorp
failed when implementing that particular idea, not that the idea itself is
necessarily flawed."
Adam
At 11:42 PM 8/12/2001 -0400, John F. Sowa wrote:
>As I have said in many notes to SUO list, I have some concerns about
>any ontology that is developed by hand. In two recent talks, I
>presented my views of how ontologies should be developed. The first
>talk, which I presented at ICCS on August 3, surveys the philosophical
>foundations. Following are the slides:
>
> http://www.jfsowa.com/pubs/signtalk.htm
>
>The second talk, which I presented at an IJCAI workshop on knowledge
>discovery on August 6, suggests automated or semiautomated methods
>of aiding in ontology development. Following are the slides for
>that talk:
>
> http://www.jfsowa.com/pubs/autotalk.htm
>
>I had originally intended to make this one talk, but as it kept
>getting longer, I split it in two. There will also be a paper,
>which I'll announce later (when it is finished).
>
>At IJCAI, I also attended a talk by Stuart Shapiro. The paper for
>that talk included some comments about Cyc, which are very relevant
>to ontology development by hand. The problems with keeping Cyc
>consistent indicate why I believe that more autotmated and
>semiautomated tools are essential for ontology development.
>I scanned the paragraphs about Cyc from the paper and included
>them at the end of this note.
>
>As I said at the SUO workshop at IJCAI, I believe that something
>along the lines that Robert Kent has been proposing for IFF is
>a necessary component of any ontology project. I would prefer
>to see SUMO split up into multiple smaller theories that could be
>combined by belief revision methods.
>
>John Sowa
>________________________________________________________________________
>
>
> Some Observations about Cyc
>
>[The following comments on Cyc have been extracted from a paper that
>was presented by Stuart Shapiro at an IJCAI Workshop (citation below).
>The evaluation of Cyc is based on Cycorp documentation and on experience
>by the first author (Frances Johnson) during a Cyc training course.]
>
>Doug Lenat and Cycorp have developed Cyc [Cycorp, 200la] -- a large
>knowledge base and inferencing system that is built upon a core of over
>a million hand-entered assertions or rules about the world and how it
>works. This system attempts to perform commonsense reasoning with the
>help of this large corpus of beliefs (mostly default with some that are
>monotonic). It divides its knowledge base into smaller contexts called
>microtheories which contain specialized information regarding specific
>areas (such as troop movement, physics, movies, etc.). Belief
>revision is performed within microtheories or within a small group
>of microtheories that are working together, and the system is only
>concerned with maintaining consistency within that small group (as
>opposed to across the entire belief space). For example: in an
>everyday context, a table is solid, but within a physics context,
>it is mostly space (between atoms).
>
>A belief can have only one truth value, so no microtheory can contain
>both p and ~p. For example, ~p could be expressed as the proposition p
>with a truth value of false. The technique for maintaining consistency
>is to check for contradictory arguments whenever a proposition is
>derived or asserted into a microtheory. When contradictions are found,
>their arguments are analyzed, and a decision is made regarding the truth
>value of the propositions involved. Rankings of beliefs, however, is
>not a part of the system -- it uses specificity to determine the truth
>value of a default belief. For example: Opus the penguin does not fly,
>even though he is a bird, because penguins don't fly. If there can be
>no decision based on specificity, the truth value of the default belief
>is unknown. A default belief loses out to a monotonic one. And,
>lastly, according to Cyc trainers and other contacts, contradictions
>that are purely monotonic bring the system to a halt until they are
>fixed. During Cyc training, Johnson attempted to prove this last
>statement and failed -- revision was performed. The instructors were
>surprised, but thought the training interface might be the cause. We
>plan to explore this further, but it is an example of a system behaving
>differently than it is described.
>
>As mentioned [above], Cyc did not perform as described, and there must
>be some question as to other possible differences from design theory.
>Most specifically, Cyc literature [Cycorp, 2001b] claims to keep the
>microtheories consistent, for lack of a better word. When asked,
>contacts agreed that, in spite of a cursory check, it was possible that
>unknown contradictions might exist that had not, yet, been derived. In
>this sense, Cyc can only guarantee that its microtheories are not known
>to be inconsistent (or KS-consistent). Ideal terminology, such as
>consistent and derivable, is often not appropriate for use with a large
>or complex implemented system.
>
>References
>
>Cycorp [2001a] _Cycorp, Creators of the Cyc Knowledge Base_,
>http://cyc.com
>
>Cycorp [2001b] _Features of CycL_, http://cyc.com/cycl.html
>
>The original article from which these paragraphs were extracted:
>
>Frances L. Johnson and Stuart C. Shapiro, "Redefining belief change
>terminology for implemented systems," _Inconsistency in Data and
>Knowledge_, Working Notes from IJCAI'01, Seattle, Washington,
>6 August 2001, pp. 11-21
Adam Pease
Teknowledge
(650) 424-0500 x571