SUO: Enchoiry on Colimits and Diagrams of Theories
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Robert,
It would help a LOT if you could rustle up
a simple example and show how all of the
details work out in a concrete case.
Myself, I just barely remember looking at a colimit diagram
once and wondering what the heck it was all about, so maybe
you could start by explaining that.
I sort of remember how one defines initial and terminal objects
in a category of diagrams. Is a diagram of theories anything
like that?
Also, I will have to find another word for module in this
categorical context, because every time you say "module"
I just can't help thinking that you are talking about
a module. I will experiment with "component" for
a while until I can think of something more apt.
Thanks To The Limit,
One More Time,
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Robert E. Kent wrote:
>
> John, Eric and others,
>
> I am probably preaching to the choir again, but I think this needs some
> comment in order for people to understand my current thinking of how the
> IFF applies to modularity and centralization.
>
> The description below is precisely the rationale and motivation for
> representing the library of modules in the IFF as a diagram of theories,
> or even as multiple diagrams of theories. Each theory can be left in place
> undisturbed. Various operations such as subsetting, summing and quotienting
> can be applied to these theories to generate new theories. If it is desired
> to compose a "great big hierarchy with modules copied in, frozen into place,
> and relabeled to avoid inconsistencies", this is accomplished in a
> straightforward manner:
>
> 1. Informally identify the theories that will be used
> in the composition.
>
> 2. Formally create a (transient, since it will be used only for this
> computation) diagram of theories T = {T_n} that indicates this
> selection.
>
> 3. Form the colimit T* = col(T) of this diagram of theories, with the
> following sub-steps.
>
> 3.i. Compute the underlying base diagram of languages
> L = base(T) = {L_n}= {base(T_n)}.
>
> 3.ii. Form the colimit L* = col(L) of this diagram of languages
> with associated colimit injection language morphisms
> {l_n : L_n --> L*}.
>
> 3.iii. Move the individual theories in T = {T_n} along the language
> colimit injection morphisms to the lattice of theories LOT(L*),
> getting the homogeneous diagram of theories flow(T) = {flow(T)_n},
> where each theory flow(T)_n = dir(expr(l_n))(T_n) has the same
> underlying base language L* (the meaning of homogeneous in
> this instance).
>
> 3.iv. Compute the meet (union) of the diagram flow(T) within the
> lattice LOT(L*) getting the colimit theory
> T* = col(T) = meet(flow(T)).
>
> The colimit T* is the desired "great big [centralized] hierarchy".
> In the larger picture, it is just another theory. The original
> theories have been left in place undisturbed.
>
> Robert E. Kent
> rekent@ontologos.org
>
> ----- Original Message -----
> From: "John F. Sowa" <sowa@bestweb.net>
> To: "Eric Peterson" <epeterson@CCAAVA.com>
> Cc: <jim.s3@juno.com>; <standard-upper-ontology@ieee.org>
> Sent: Friday, June 27, 2003 3:21 AM
> Subject: Re: SUO: Re: Charter vs. Consensus
>
> [snip]
>
> > That is just a repackaging of exactly the same mathematics, but
> > to avoid inconsistencies, it uses relabeling instead of modules.
> > However, I have not given up on modules. They are an essential
> > step toward the development of the single hierarchy, and they are
> > much more flexible for the development of special purpose ontologies.
> >
> > We could have both. If you want to regard the single hierarchy
> > with lots of relabeled subtypes as "The Standard", be my guest --
> > just as long as each of the subtypes is cross indexed to some module
> > or modules in the registry from which the axioms were derived.
> >
> > Nevertheless, the modular approach gives you vastly more flexibility
> > and potential for reuse. It allows you to reuse the same modules
> > in different ways in different places. When you import a module into
> > the big hierarchy and relabel the names to accommodate the particular
> > position into which you inserted it, it is very hard to extract it
> > again and reuse it somewhere else.
> >
> > And by the way, I never used the word "competing" for the modules,
> > and the single hierarchy just moves any "competition" between modules
> > into competition between disjoint subtypes. I would prefer to say
> > that the modules are complementary, since many of the more general
> > ones can be reused in multiple ways in many different places in
> > the big hierarchy.
> >
> > Summary: I regard the lattice of modules to be the most important
> > ontological resource we could develop. But I have no objections
> > to having a great big hierarchy with modules copied in, frozen into
> > place, and relabeled to avoid inconsistencies.
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o