SUO: Re: Loading the Hierarchy
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
T
o==o==o=====o==o==o
| | | | | |
| | | | | |
o o o o o o
\ | / \ | /
\|/ \|/
M_1 o o M_2
\ /
\ /
\ /
\ /
\ /
o
_|_
John,
The reasons for indexing code modules in the library or registry or whatever
according to their "stewards" -- "informants", as they say in anthropology and
linguistics, "reponsible parties", "communities of interpretation", "warrantors",
as they say in other places -- have as much to do with knowledge base integrity
as they do with module identification.
(Here I am thinking of finite axiom sets and finite sets of predicates,
whether computable predicates or the other kind, in a given language L,
as being the sorts of things that can be coded up in finite strings of
some extension of L's alphabet.)
In other words, I am taking about "accountability through audit trails" as they say
in finance and government, "design for testability", "design for diagnostics", or
"design for error-correction" as they say computer science and engineering.
Now, we all know that credit-fault attribution is as old as Checkers and his boy Nixon,
and no doubt there is a theorem somewhere that says "no-go" to the design of a perfect
system, and we all, well, some of know that when you find a contradiction deriving from
a set of axioms, explicit and implicit, that there is almost always more than one way to
point the fault finding fingo of blame.
Still, a little bit of strategic thinking at the offset,
which accepts the inevitability of fallibility in human
design, can make a big difference in long-run reliability.
And keeping every predication indexed by its predicator
is one good way of doing this.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
sowa wrote:
>
> 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
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o