SUO: Re: Building the Hierarchy
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
John,
I will try to go through these points in more detail.
John 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".
For my part I have found it best to focus first on interpretive agents,
customs of usage, communities of interpretation, or "language games" if
you prefer. The reason is that you can study the structure and function
of such things at a much earlier stage of development than a full-fledged
axiomatic theory. There are formal systems that are useful in empirical
and ethographic research that have only the structure of formal languages,
that is, L c A* for some alphabet A, that are not yet full-blown logical
theories, but only code in a near-literal way the event sequences that
occur in a given empirical domain. For example, protocol analysis.
They store information about their object domains in the distinction
between the sequences of A* that are in L and the sequences of A*
that are not in L. Maybe one can discover a grammar for L -- there
was a time when I used to read papers on "Gerbil Grooming Grammars"
and such -- and then one has something more like a generative theory
of L, but this may or may not happen. In these situations, one is
stuck with ordering the possible languages according to the lattice
Pow (A*).
Both Pers, on his clear way, and Ludovico, in his peculiar way, continually
stress this very same point. Now you know that interpretive agents are sops
that are disposable in favor of the relevant triadic sign relation itself, but
it seems like a fairly harmless form of personification to continue using them,
so long as we all know what they mean in practice.
> 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".
There are two main dimensions of variation, connotative and denotative. Again,
for concreteness, consider SemiTruck_US and ArticulatedLorry_UK. I gather from
BBC and PBS that these are roughly equivalent, denotation-wise, but I'm not real
sure if the correspondence is exact. Connotation-wise, the second handle seems
like it would sound kinda funny in a country-western song.
> 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.
I'm not sure I understand what you have in mind here.
It doesn't seem to me that Set_SUMO or Set_Cyc would
sit to well with Set_Math of any flavor -- maybe you
could identify one or two axioms that, if they are
viewed superficially enough, appear to be shared,
but how can you extract Set_X from the context
of Community_X, when each of the words that
Community_X uses to define Set_X have
their own special senses, bound to
the rest of System_X?
> 2. Two names, even with the same spelling, in
> independently developed modules could not be
> assumed to have the same intended referents.
Right.
> 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).
This notion of "All" is the unchained malady of mathematics.
It has time and again proven to be advisable to relativize
even the most universal of predicates to particular objects
in particular categories. This is one of the reasons why I
consider it a big step backward from Peirce's Sigma and Pi
to later uses of Existential and Universal quantifiers.
In math, there is no automatic notion that an indicated
sum or an ostensible product makes any kind of sense
except under the most exactly specified conditions
on the domain and the method of forming limits,
and there is no reason that logical quantifiers
should be regarded any less circumspectly.
I'll continue from this point later.
Jon
> 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