SUO: Re: Building the hierarchy
After the recent flurry of comments, I decided to redraw suohier.gif
to clarify some of the issues. The diagram suohier1.gif is a slight
modification to the original, which colors the consistent modules green.
The bottom is colored red to show that it is a "red flag" that indicates
danger, rather than a module that anyone would actually use.
(Note: I'm giving SUMO and OpenCyc the benefit of the doubt by coloring
them green, even though their consistency remains to be proved. The
smaller modules, however, should be small enough that consistency can be
proved; if not, they should be subdivided until the proof is possible.)
In his note, Richard Cooper suggested that the upside-down T, which is
commonly used to indicate the bottom node of a lattice, should be replaced
by a string that uses only the Ascii character set. He suggested the
letter F, but I renamed it Inconsistency to indicate that it is an
inconsitent theory (which therefore implies everything).
The second drawing, suohier2.gif, shows a later stage in the development
of the hierarchy, after some collaboration between the SUMO and OpenCyc
groups. The modules in blue represent smaller, more general theories,
many of which are common to both groups and can be shared by them (or
by anyone else who might find them useful). The large theory in the
middle (colored yellow) represents a customized ontology that somebody
derived by combining the S3 module from SUMO, the O2 module from OpenCyc,
and some of the blue modules. (It might also include some specialized
axioms that were not taken from any other modules in the hierarchy.)
Both of these diagrams are also on my web site:
http://www.jfsowa.com/figs/suohier1.gif
http://www.jfsowa.com/figs/suohier2.gif
Following are some further comments on the other notes:
1. Pat Cassidy suggested that the smaller modules be prefixed with a
string that indicates the original ontology from which the module
was derived. However, more information is needed than a simple
string could provide:
a) Many modules in both SUMO and OpenCyc were derived from other
sources in the published literature (possibly with some further
customization). Those sources should also be indicated somewhere.
b) As the suohier2.gif diagram shows, it would also be desirable to
include modules that were derived from (or inspired by) two or
more different sources.
Rather than encoding the derivation history in the name, it would be
better to include documentation with each module that indicates its
source, its revision history, and references to any other information
that could explain the axioms and their intended meaning and use.
2. Seth Russell suggested that a module name should be "a real URI",
which would be consistent with the W3C conventions for identifying
resources on the WWW. I think that is probably the way we should go.
3. Jon Awbrey raised some very important issues, which some of the
ontology projects have addressed to certain extent, but they must be
addressed by everybody who is working on practical applications of
any ontology. Following is one of Jon's examples:
"In use, we have to decide whether to rely on Geometry_FlatEarth,
Geometry_Spherical, Geometry_Relativistic, and so on, to chart our
course, say, by shuttle from one's home to the airport, by plane to
the other side of the country, by copter to the other sort of shuttle
port, and beyond. The different maps have overlapping domains of
application, and keeping them separate in our imagination is helpful,
but doesn't help tell us when to use what, or help to resolve the
differences of opinion or customary practice. Billions of bucks and
maybe even some lives have been lost because of different working groups
using different systems of coordinates."
Another example is the limited ontology of medical problems that most
people use compared to the much more detailed ontologies used in the
medical profession(s). When a patient talks to a physician or a PhD
talks to an MD, their words and the theories associated with them
don't line up in any simple way, and a lot of adjustment is necessary
on both sides before, during, and after any communication.
4. Jon also observed that organizing modules in a hierarchy is like
posting notes on a structured pegboard, which may be useful for
classifying them, but it doesn't address a large number of issues
about what they mean, what concepts to formalize, and how to formalize
them. I agree with him on these points, and I must emphasize that
any classification, such as the hierarchy of modules, is only one
part of a much larger puzzle. I believe it is a necessary piece
in the puzzle, but there are a lot more pieces to be put in place
before we can develop an adequate set of tools and a methodology for
using them to design ontologies and the applications based on them.
5. Robert Kent pointed out the difference between a theory and an
axiomatization of a theory. In logic, the word _theory_ is applied
to the "deductive closure" or the complete set of implications of
some axioms. Since two or more axiom sets might have the same
implications, the axiom sets are in a many-to-one relationship
with the lattice of theories. Technically speaking, the hierarchy
of modules (axiom sets) would only be a "preorder", not a partial
order, since it might include different modules that have identical
implications. This is an important point that must be noted in the
complete documentation for an SUO standard.
6. Robert also noted that the full IF framework is designed to accommodate
multiple versions of logic, each one of which would support an infinite
lattice of theories. IFF is capable of relating theories in different
lattices expressed in different logics. For the initial version of the
SUO standard, however, we have only been conisdering theories expressed
within the Common Logic (CL) family (assuming the CycL can be defined
as a member of the CL family). It is useful to note that IFF will be
able to handle multiple logics, but for the first version of the SUO
standard, that full generality may not be needed.
7. On a separate thread, Adam Pease made the following point:
"We do ontology merging with content ontologies and so we know what
the practical steps are. We know how to extend SUMO in other domains.
But I don't know how to use IFF and how it would have value so I'm
waiting for research results from you that might illustrate the first
example of how to perform that process."
The suohier1 and suohier2 diagrams illustrate some additional steps,
which are eminently practical and which require at least a subset
of IFF. There is a lot more to be said, but I believe that the steps
from suohier1 to suohier2 would be valuable for many, if not most
users, including the people who develop and maintain SUMO and OpenCyc.
I'm sure that there are many other issues that can and should be discussed,
but I just wanted to post this note to indicate that the minimum amount of
formalism included in the joint motion is sufficient to cover an important
set of operations that can help design and relate ontologies. The people
who are developing IFF can work with the SUMO and OpenCyc developers to
determine how much more should be included in the standard. And the
issues that Jon Awbrey raised should also be addressed by the tools,
the methodology, and the documentation that accompanies them.
John Sowa
