Re: SUO: Is an SUO feasible? -can a registry help?
The term "module" emphasizes the modularity and the ability to
assemble modules into larger modules. But the important point is
that everything in the registry is a module, no matter what its
size. All of SUMO could be a single module in the registry,
and all the submodules from which it was assembled could also be
in the registry as independently usable modules. All of OpenCyc
could be a single module in the registry, and all its submodules
would also be in the registry.
The advantage of combining a registry with the lattice operators is
that the combination would provide a mechanism for registering and
certifying each individual component module as well as operators for
assembling the component modules to create new versions that are
tailored for different kinds of applications -- they support the
"mixing and matching" of modules, so to speak.
PC> On the issue of a registry, I have, as I mentioned, no objections,
> but I am unclear as to how a registry would differ from a list of
> candidates for SUO that have been approved by this study group.
A simple registry would be just a list. But the lattice operators
make it much more than a list. Each of the candidates could be in
the registry as very large modules. But their component modules
would also be in the registry, and users who had applications for
which the larger modules were unsuitable could decide to assemble
their own ontology by taking component modules from different sources.
If the result of that mixing and matching proved to be useful, the
developers could register the new combination as another module
in the registry, which other developers could adopt, build on, or
PC> This emphasizes one way that a standard ontology differs from
> other types of standard, namely that the desired updates will
> likely be submitted frequently. At the uppper levels, however,
> we may well find that requested updates become less frequent over
That is another reason why modularity is important. Some modules,
especially the more fundamental ones at the upper levels, are likely
to remain stable for long periods of time. But other modules at
lower levels may change much more rapidly. That is an important
reason for keeping them all in the registry with a history of all
The lattice also records exactly which modules depend on any other
module: if A is above B in the partial ordering, then any change to
A would affect B, but no change to B would affect A. When updates
are made, the developers can just check the dependencies to see
whether any of their applications are affected. If the entire
ontology is replaced as one big lump, there would be no way keep
track of which applications would be affected by any of the changes.