SUO: Modularity
The most fundamental criticism of the SUMO proposal is its lack
of modularity. Some people have maintained that this is an issue
on which we should "agree to disagree".
However, modularity is so essential to good design decisions
in every area of engineering -- mechanical, civil, electrical,
chemical, and most of all knowledge engineering and software
engineering -- that any proposal to ignore or abandon modularity
must be considered uninformed or incompetent.
Since very little has been written about ontological engineering,
there is very little published literature in the field that we
can point to, but the literature on behalf of modularity in all
other areas of engineering is overwhelming.
In an earlier note, I cited Herb Simon's discussion about
the need for modular designs in his article on architecture
of complexity. As an example, he cited the parable of the
two watchmakers. That example is summarized in the following
article (which also discusses other methodologies for handling
complexity -- none of which, by the way, recommend the
monolithic approach):
http://www.scenarioplus.org.uk/handwritten/historical/historical_text.htm#Simon
As a good discussion of modularity in software design, I suggest
the following article by David Parnas, which has been selected
as a "classic paper" by the ACM:
http://www.acm.org/classics/may96/
Following are some quotations from the article with my commentary
about how they apply to the task of designing an ontology.
I recommend the entire article, even though some of the programming
issues are not directly applicable to ontologies.
John Sowa
_____________________________________________________________________
At the beginning of the article, Parnas quotes the following
paragraph by Gouthier and Pont, who were talking about system
programming, but the discussion applies equally well to ontology:
A well-defined segmentation of the project effort ensures system
modularity. Each task forms a separate, distinct program module.
At implementation time each module and its inputs and outputs are
well-defined, there is no confusion in the intended interface with
other system modules. At checkout time the integrity of the module
is tested independently; there are few scheduling problems in
synchronizing the completion of several tasks before checkout can
begin. Finally, the system is maintained in modular fashion, system
errors and deficiencies can be traced to specific system modules,
thus limiting the scope of detailed error searching.
Then Parnas discusses the benefits of modularization, which are also
important for ontologies:
1. Managerial: development time should be shortened because
separate groups would work on each module with little need
for communication.
2. Flexibility: it should be possible to make drastic changes
to one module without a need to change others.
3. Comprehensibility: it should be possible to study the system
one module at a time. The whole system can therefore be better
designed because it is better understood.
At the end of the article, Parnas concludes with an interesting
observation the criteria for deciding how to modularize:
We have tried to demonstrate by these examples that it is almost
always incorrect to begin the decomposition of a system into modules
on the basis of a flowchart. We propose instead that one begins
with a list of difficult design decisions or design decisions which
are likely to change. Each module is then designed to hide such a
decision from the others. Since, in most cases, design decisions
transcend time of execution, modules will not correspond to steps
in the processing. To achieve an efficient implementation we must
abandon the assumption that a module is one or more subroutines,
and instead allow subroutines and programs to be assembled
collections of code from various modules.
Some of this discussion relates to flowcharts and subroutines,
which do not relate to the development of ontologies. However,
the idea that modularization should be based on "difficult design
decisions or design decisions which are likely to change" is
a very important insight.
We have come across many "difficult design decisions" in the SUO
discussions, and every one of them is a good reason for creating
a module.