SUO: Re: Building the Hierarchy
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
John,
I am assuming that some sort of pegboard arrangement can be worked out
for organizing the modules of axiomatic code or program code that are
completely formalized. This would be a nice hierarchy of some sort,
with a place for everything, and everything in its place. But if
you think about the clasical examples that I've been mentioning,
you will see that this won't solve the sorts of problems that
we've been having here.
In one sort of problem, even though we've nicely parameterized all of the
different axiom sets, say, for geometries, so that they can be sorted out
to different spots of the pegboard, that only handles what to do with them
when they are not actually being used. 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. Having half
you pegboard labelled "metric tools only" is helpful,
but it doesn't yet address the problem of overlapping
applications.
In the other sort of problem, as instanced in mathematical practice
by Set_Naive and Set_Axiomatic, the catch is that you don't have an
axiom set to pin on Set_Naive. The two concepts exist at different
levels of formalization, and so there is in general an irreducible
tension along the dimension of formalization itself. Set_Naive,
which is what most folks probably trust most of the time, except
when teaching or taking an exam, is not so much defined by axioms
as aphorized by aphorisms and fleshed out by familiar examples.
For these sorts of reasons, we have to be able to reason about concepts
that are not completely formalized and not yet modulized, and so, once
again, we see that axiom sets, beautiful as they are, come rather late
in the life-cycle of a useful concept. What you do have, long before
you have axiomatic definitions, if ever, is semiotic processes, where
the very same signs have very different interpretants, as exibited
between and even within different communities of interpretation.
In this connection, I think that the "atlas of charts" metaphor,
as it is used in manifold theory, provides a necessary supplement
to the hierarchy or lattice or partition metaphors.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
sowa wrote:
>
> Jon,
>
> Some strategy for distintuishing the identifiers
> used in different modules and relating them to
> one another is essential. I'm renaming this
> thread "Building the hierarchy" because it
> addresses some important general principles.
>
> The first point to note is that every module in
> the hierarchy should have a unique identifier.
> Therefore, all names could be distinguished by
> a concatenated string such as "moduleID.localId".
>
> Keeping the names distinct is not a problem.
> The real problem is to have a systematic way
> of specifying the conditions for determining
> how and whether identifiers in different
> modules could be assumed to be "the same".
>
> As you noted in your email, one might assume
> that the SUMO names or the OpenCyc names had
> been coordinated with one another so that
> we could assume:
>
> 1. Two names with the same spelling in two
> modules that had been extracted from
> some larger module would have the same
> intended referents.
>
> 2. Two names, even with the same spelling, in
> indepedently developed modules could not be
> assumed to have the same intended referents.
>
> The purpose of the lattice of theories (or at least
> a generalization hierarchy that represents some
> finite excerpt from or some finite step toward
> such a lattice) is to relate the names in
> different modules.
>
> At the start of the joint project, we begin with
> a one-node hierarchy: just the universal theory
> T at the top (the one with no axioms at all).
> Then we would put two big nodes on two separate
> branches under T: for example, OpenCyc on the
> right branch and SUMO on the left branch.
>
> The next step would be to extract smaller modules
> (or microtheories) from the two big theories.
> Each of the smaller modules would be more general
> than the larger module from which it was extracted.
> Therefore, all the SUMO modules would lie on some
> branch between T and SUMO, and all the OpenCyc
> modules would lie on some branch between T and
> OpenCyc. The hierarchy at this step is shown in
> the attached file, which I also put on my web site:
>
> http://www.jfsowa.com/figs/suohier.gif
>
> Following are some general principles, which apply
> to this hierarchy and any others that are organized
> as a generalization-specialization hierarchy:
>
> 1. Every module is consistent with all its
> generalizations (i.e., those that lie on
> any upward path between it and the top).
>
> 2. Every module is consistent with all its
> non-absurd specializations (i.e., those that
> lie on any downward path between it and the
> absurd theory at the bottom).
>
> 3. Any two modules whose only common specialization
> is the absurd theory at the bottom are assumed
> to be inconsistent (unless proven otherwise,
> in which case their merger could be added to
> the hierarchy on a branch below each of them).
>
> 4. Any two modules whose only common generalization
> is the universal (or empty) theory at the top
> are assumed to have nothing in common (unless
> proven otherwise, in which case their common
> generalization could be added to the hierarchy
> on a branch above each of them).
>
> Constructing a hierarchy similar to suohier.gif
> would be fairly straightforward, and even at the
> beginning stage it would be a useful thing to have
>
> Even more useful, however, would be a refinement
> of suohier.gif to find commonalities between SUMO
> and OpenCyc and to find features of each that could
> be used to enrich the other (i.e., to fill in the
> "no man's land" between the two branches).
>
> The purpose of the lattice operators is to provide
> guidelines that show where to look for the
> commonalities and missing information and where
> to put the results when they have been derived.
>
> Bottom line: Building the hierarchy can be done in
> a step-by-step fashion, and even the early stages
> can be useful to the SUMO and OpenCyc developers
> and anyone else who needs ontology building blocks.
>
> John Sowa
>
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o