Re: SUO: Modularity
Frank,
There is no such thing as a "monolithic engineering project".
Every major project in every field from computers and watches
to airplanes and skyscrapers has been developed in a modular
fashion. If you can think of any successful exception, please
let us know, and we'll show you that it is indeed modular.
And please reread the paper by David Parnas. As he points out,
there are many ways to modularize a project, and some of them
are far better than others. His basic criterion, which can be
transfered to any kind of design problem is to study the points
where hard decisions have to be made. Those are the places
where modules should be created.
Finally, we have been proposing a framework that is solidly
based on fundamental principles: the Lindenbaum lattice of
theories, which provides the foundation for organizing any
collection of theories and for merging them automatically.
Some comments on your note:
> Although John Sowa has provided some stories about modularity, in
engineering it is only one design methdology (read: works sometimes
in certain contexts).
I agree that modularity is only one design methodology, and others
are needed. Most other methodologies are built on top of or in
conjunction with a modular structure. And as I said above, please
show us *any* successful large project that you believs is not
modular, and I will show you where the modules are.
> In this area of engineering (mostly software engineering),
modularity was introduced in the late 1960's through the 1970's....
Wrong! Modularity was introduced with the invention of the brick.
It was the foundation for interchangeable parts, and the industrial
revolution would have been impossible without it.
>However, it has had big failures, too: the Mythical Man-Month
(a classic book on software engineering methodology) documents how
modulary can be a very bad thing, e.g., trying to exchange 1 programmer
and 10 months of work schedule for 10 programmers and 1 month of work
schedule.....
Wrong! That is not the lesson Freddy B. was trying to get across.
His point was that you can't chop a job into pieces until you know
where to make the cuts. You have to start with a solid design that
shows what to modularize. That is also the point Parnas was trying
to make.
As an example of how to modularize an operating system, I suggest
Dijkstra's classic paper on the THE Multiprogramming System:
http://www.acm.org/classics/mar96/
This is the appendix to a famous paper, in which Dijkstra discusses
how he designed the system. But before he did the modularization,
he developed appropriate primitives to support it, including the
now ubiquitous "semaphores". That system has had a major influence
on all subsequent OS projects.
And as for OS/360, the 1965 version of the high-end system was
called VMS (Variable Memory System) in which any program could
execute the GETMAIN and FREEMAIN macros to allocate and free
memory from a single pool. That tended to work on the smaller,
slower versions of the System/360 hardware, but the larger,
faster systems usually deadlocked in less than 15 minutes.
As a result, they did a systematic modularization based on
the "hard design decisions", namely how to avoid deadlock,
and the resulting system, called MVT, evolved into MVS,
which evolved to become the current OS/390, which holds the
record for being the most reliable of all major commercial
operating systems.
> The main reason not to "go modular" is coherency and consistency,
e.g., high-level design can have some significant integration,
compatibility, and communication problems with a so-called modular
approach. Typically, a "modular" approach works well in low-level
design, **where the high-level design has already been agreed upon**.
You are partly right. The high-level design must be agreed upon
before you do the modularization. But that is exactly what
Parnas and Brooks were saying.
> We are working on the high-level design (presumably the "upper" in
SUO), so I wouldn't expect modularity to be a particularly useful
methodology tool **at this point in time**....
No! The upper ontology is *not* the high-level design. What
the SUMO developers are now doing corresponds to "writing code".
They are not doing design. There is no design for SUMO. It
is just a big collection of axioms, which have *not* been tested
for consistency, coherence, or any other good buzz words.
> In the context of standards activity, I think just about every committee that I've participated in had someone say "let's do this modular" (presuming, like John, that this is a cure-all)....
I never said it was a cure-all. There is much more to design
than choping things into modules. Please reread the paper by
Parnas. What I merely said is that modularization is a
prerequisite, and that it must done according to a well-thought
out design. We have been talking about that methodology for
years. Please reread all the past SUO notes about contexts,
the Lindenbam lattice, etc., which are documented in many books,
papers, etc.
> - In the very early stages, it makes little sense to break a project into smaller pieces because the overall structure of the work has not revealed itself.
I agree. We are at the stage where we should agree upon a high-level
design that should show how to do the modularization. But the SUMO
effort has jumped into the low-level coding stage without any design
for any structure of any kind.
> - Committees that have prematurely split their projects (even if the projects are staffed by the same participants) suffer from the same problem in the Mythical Man-Month: maintaining communication, coordination, coherency, and consistency among the projects/pieces is a significant delay to the work....
I agree again. I was not asking to split the project. I was asking
for a high-level design that would show how to do the modularization.
> - Wait until the latter stages of the work to break a project into pieces. The partitioning may be easier when the larger perspective has revealed itself. For many standards committees, the larger picture may take a while ... sometimes it takes 1-3 years just to discover the "right question to ask".
Please note: The SUO project is a successor to the knowledge
sharing effort that was started in 1991 (from which KIF emerged),
a series of ontology workshops that were sponsored by NCITS T2
from 1996 to 1997, a workshop in Heidelberg in 1998 and many other
workshops on contexts and related topics. This is not the early
stages. There is a lot of expertise about how to design ontologies
that has been ignored by the SUMO developers.
Following, by the way, is my position paper from March 1991:
http://www-ksl.stanford.edu/email-archives/srkb.messages/17.html
It discusses the problems that face any monolithic ontology of
any kind, and it most definitely does not consider modules as
a cure-all. (It also contains a pointer to the full SRKB
archives, if you want to see what other people have said.)
For the archives of the 1996 and 1997 X3T2 efforts, see
http://www-ksl.stanford.edu/onto-std/
> - A so-called "modular" approach could be applied to any standards activity, e.g., each clause could be a separate part of a multi-part standard....
Of course that's stupid. Please reread the paper by Parnas.
His crucial point is that you don't chop a system into modules
accoring to a flowchart or a standards document. You look at
the "hard design decisions" to determine where to modularize.
AT> I would argue for the notion of modularity and PARTIAL sharing of
> > ontological commitments in some communities. See the work on Partial Share
> > Views done at MIT Sloan School for example as part of the PIF work.
FF> In the context of ICSs (implementation conformance statements), how
would this work with uses of the SUO standard: what standard(s) would
they claim conformance to?
What should be standarized is the framework that contains the modules,
and the modules that plug into the framework. The Lindenbaum lattice
provides a framework that shows exactly which modules are dependent
on which other modules. Each module can be registered with its
own version control information, its certification and testing info,
etc. Projects can agree on exactly which modules they share, and
they can continue to use those modules for as long as they like,
independent of the change procedures for other modules that do
not affect them.
FF> If we're expecting to be replacing broken/unstable parts, then we
shouldn't be including them in a standard. This is one difference
between standards development work and software development work.
Good point! But what you are saying is that no SUO could ever
qualify as a standard because there can be no such thing as a stable
ontology for everything. Cyc, for example, has been in development
for over 17 years, and every level (even the top) has undergone
major revolutions and evolutions.
What Austin and I and many others have been recommending is a stable
framework that makes room for modules with varying levels of stability.
You can have some well-understood mathematical modules that are rock
solid, certified, and stable. Other modules may be in continuing
stages of flux. But anything that two or more projects decide to use
can be registered in the registry, even though they may eventually be
replaced.
> Regardless of how you partition the work, *every* user will need to be aware of what "edition" (in standards speak) of SUO they are using. In your paragraph above, I suggest that we only include in SUO the portions that are "very stable and well justified and shared across very broad communities"....
Now we are making progress. If you equate "portion" with "module",
we can begin to talk. My only addition is to say that any
"portions" or "modules" will have varying levels of stability,
and they belong in a registry that states their level of testing,
validation, and certification.
> Although I can't put my hands on it, I think Cambridge University published a dictionary that had a "core" ~2000 words in it ... all definitions outside the "core" were defined in the words of the "core". The dictionary didn't have "core" and "non-core" sections, they were combined into the familiar A-Z organization. This was a very useful dictionary in many ways, including its organization into a single "monolithic" document.
That was LDOCE (Longman's Dictionary of Contemporary English).
That core wasn't really sufficient, since they did make a lot of
extensions, which they flagged as needed. But one very important
point about dictionaries is that they are the most modular of
documents: every definition is an independent module, written
by different lexicographers and verified by different editors.
There are many similarities between dictionaries and ontologies,
but a full discussion would take much more time, effort, and space.
> Regarding the partitioning of SUO, I think it is too early to tell whether we want one standard or several.
No. We need one standard for the framework and a registy for the
modules.
> Like this Cambridge dictionary, change control can be as quick or slow as you want it to be. Within IEEE, we could probably process a Technical Corrigendum (TC) in about 3-6 months ... it depends on several factors. FYI, a TC is just like the standards process: it is possible to approve a standard in 3-6 months, but committees don't -- Why? Because there are business and technical reasons that cause the process to take longer (read: there are good reasons for things taking longer than the minimum time). In other words, the "slowness" of change control has little to do with the IEEE standards process.
Changes that take place every 3 to 6 months can be very difficult
to accommodate for developers who use the ontology. That is why
it is essential to have a framework of modules, where the stability
of each module is independently certified.
> Regarding "universal consensus", we only require IEEE-SA consensus (75%). You should see this different than software engineering: our goal in standards development is to publish stable specifications. If we publish unstable specifications, there will be little market adoption of our work (which is a time-waster for everyone).
I certainly agree. A vote of 17 yes, 16 no, and 9 abstentions is
about as far as you can get from any like a "consensus".
> - We should develop a common set of guidelines, criteria, etc., for what goes into SUO (or SUMO or IFF). The result would be more consistent work. (<-- a summary of one of my ballot comments on SUMO)
I agree. And that is the framework that I have been talking about
for the past 10 years (see the archives of the knowledge sharing
effort and the ontology effort).
> - We should work on the "conformance clause", i.e., how do we know if an "implementation" (e.g., a system) conforms to SUO? (<-- again, a ballot comment on both SUMO and IFF)
I agree. And the clear distinction between the framework and the
collection of certified modules would make it easier to state and
test conformance.
John Sowa