SUO: Modularity (what it's not and other topics)
[This E-mail is somewhat long. I've looked at John Sowa's papers and references and provide a rebuttal. In case you get tired of reading this, one of the main points is repeated at the end. -FF]
At 12:33 2001-09-29 -0400, John F. Sowa wrote:
> 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.
The high-level design (which was my point in the previous E-mail) doesn't benefit as much from modular design. All the examples you listed above, don't benefit from "modular" high-level design:
- What is the point of designing an airplane (high-level design) if the airframe and powerplant teams aren't working on the same design? You can't design an airplane by having the airframe folks working independently from the powerplant folks.
- Same is true for watches and skyscrapers.
- Computer systems, many times, are built "bottom-up" from components ... there is some high-level design.
Again, please understand that I am talking about high-level design ... I believe this is the partitioning problem we are addressing.
> 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.
I did re-read the paper. The paper was written in 1971 and much has since been learned about this kind of engineering (mostly software engineering). While I don't disagree with many of the points in the paper, much has happened in engineering since then. It's conclusion isn't particularly strong:
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.
OK, don't decompose a system based on components of a flowchart. Can't disagree, but the statement doesn't really apply to SUO.
Another statement "Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing" is inconsistent with his paper since the two "successful" modularizations correspond to the steps in the processing. I'm not disagreeing with his examples of successful modularization (in those examples, they were appropriate), but I am disagreeing with his conclusions (the author seems to be unaware that his successful example is in disagreement with his conclusions).
The statement "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" seems relevant in the context of a programmer in 1971, but it doesn't generalize even to software engineering ... I doubt it applies to SUO.
Your claim:
His basic criterion, which can be transferred 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.
just doesn't apply to most of engineering. For example, the hardest decisions in designing a disk drive might be price, speed, capacity, reliability, power, transfer rate, and temperature ... but none of these will be partitioned into a particular modules. In the example of a plane, probably the most important design factor/decision is "wing loading", i.e., how much "lift" per square foot, but there is no separate "wing loading" component on a plane -- wing loading is a feature of the wing, the engine(s), the control surfaces, etc., not just one isolated component.
In fact, one might say that great engineering occurs when you can hide the hardest decisions, i.e., their boundaries aren't visible at all.
> 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.
OK, so what standards wording are you proposing?
> 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 believes is not
> modular, and I will show you where the modules are.
My point was the high-level design, and I've given examples.
> > 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.
Sorry John, but that misunderstanding of modularity is what caused people to make mistakes in the 1960's (as documented in the Mythical Man-Month). While bricks may be created individually and used independently, that analogy does not apply to software engineering. In the late 1970's, more was understood about the distinction between top-down (e.g., high-level) design and bottom-up (e.g., brick) integration.
The brick-mentality created these failures in the 1960's. It was later understood that dependencies (e.g., communications) were the cause of these failures. The result was to reduce the partitioning, not to create more. Later on, the same brick-mentality was applied to the object-oriented paradigm, which has had its own successes and failures.
Largely, the generic problem is trying to map the brick paradigm into every scenario, and it only applies in certain cases. This is what I believe you are doing: applying the brick paradigm in a scenario that is inappropriate (e.g., high-level design).
And a brick is not a good illustration of modularity, it is an illustration of smaller and smaller components of a larger whole. Rooms in a house might be better illustration of modularity, but not a good illustration of your point that boundaries are based on the most important decisions.
> >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.
I think you missed the point of that book: even if you know where to make the cuts, you still run into significant inefficiencies (e.g., communication). My quotation might not be exact, but one of the main slogans of the book was: "adding more people to a late project makes it later" -- this has nothing to do with "knowing where to make the cuts". So the communication problems for programmers still exist, regardless of the design. The Mythical Man-Month was largely about technical management issues, not primarily about good design methodology.
...
> > 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.
It seems to me that the SUMO developers are writing standards wording, which someone has to do. I agree that there should be consistency, coherence, etc. ... this is why I suggested developing a "criteria" paper.
Within the standards process, we need to suggest better wording if we don't like the current wording. What are your suggestions? I really think you should try to write some standards words and contribute it to the SUO group.
For example, if you believe that certain axioms should be part of SUO, then how will you express them? I guess one can use natural language, but I think most of us would agree that code-like notations (e.g., KIF or KIF-like) can be concise and precise. So if you want axioms in SUO, but don't like code-like notations, then what do you propose? (FYI, CGs are like KIF; I'd consider CGs code-like; and I'd definitely prefer KIF over CGs because KIF seems to be better defined.)
If you don't want people volunteering time to contribute axioms, then how do you see us getting to a SUO standard?
What wording do you propose? (You respond to me via E-mail, but don't suggest specific standards wording. I'll like to see your proposal for specific standards wording.)
> ...
> > - 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.
Yes, I'm aware of the long history. However, in terms of standards development, it appears in early stages. Why? There are at least two indicators:
- We don't have a conformance clause.
- We don't have strong consensus (75%) yet on standards wording or anything close.
Right now, we have two documents, with willing volunteers to contribute wording towards building further consensus. Hopefully, we'll spend time soon on a conformance clause.
> 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.)
John, I read your paper and, overall, it isn't a paper that really discusses "the problems that face any monolithic ontology of any kind". What the paper does discuss is:
... Such knowledge bases can be shared and reused, but only for other projects that are similarly restricted. The position taken in this paper is that such compartmentalization is inevitable: all deep knowledge is domain dependent. Only superficial, syntactic knowledge carries over from one domain to another.
OK, I see the point you are going to make in the paper but, unfortunately, your examples/illustrations are weak or incorrect. Here's the summary of your paper:
[Illustration #1 from John Sowa's position paper:] Many different projects have surface similarities that seem to suggest that shared knowledge representations are possible. Expert systems designed to assist automobile drivers, airplane pilots, ship captains, and locomotive engineers, for example, would seem to have a lot in common. All of them must deal with time, speed, and distance as well as fuel consumption, equipment condition, and passenger safety. Programming languages also have a great deal in common, as the following assignment statements seem to indicate:
APL: X <- A + B
FORTRAN: X = A + B
PL/I: X = A + B;
Pascal: X := A + B;
Yet these surface commonalities mask serious differences in detail. A deeper analysis indicates that the similarities are more syntactic than semantic: the concepts required for each domain are so tightly bound to that domain that they cannot be mapped from one to the other. ...
You go on to explain that there are subtle differences between the semantics of the addition operator in all four languages and how they cannot be mapped to each other. However, in the early to mid 1990's, several ISO/IEC standards were developed (ISO/IEC 10967-1, Language Independent Arithmetic; ISO/IEC 11404 Language Independent Datatypes) that provide the common understanding and mapping (also known as a "binding" in standards speak) across all the programming languages and database systems. While the behavior of APL might be different than Fortran, these LIA/LID standards provide a common understanding that can be mapped from one language to another. The purpose of these standards was to develop inter-language and language-independent capabilities.
So your assertion "the concepts required for each domain are so tightly bound to that domain that they cannot be mapped from one to the other" is false, as demonstrated by the LIA and LID standards.
[Illustration #2 from John Sowa's position paper:] First consider the possibility of common knowledge bases for automobiles, airplanes, ships, and trains. A major difference between these domains is the number of degrees of freedom in the motion. A train's motion is purely one dimensional because of the rigid tracks. At a gross level, a car's motion is also one dimensional, but at a detailed level, the driver must maneuver in two dimensions to keep the car in lane and avoid other cars and obstacles.
A ship's motion is also two dimensional, but its greater inertia causes a change in course to take minutes instead of the split-second changes that are possible with a car. An airplane's motion is three dimensional, but changes in attitude introduce three more degrees of freedom. Besides differences in motion, there are different kinds of signals to consider and different ways of planning a course and following it.
As a result, a driver, a pilot, a captain, and an engineer have totally different ways of thinking and reacting. A person who is both a driver and a pilot would have two independent modes of thought with little or nothing in common. Expert systems designed for each of these domains would also have few common concepts and practically no common rules.
In train and aviation traffic control systems (which I am familiar with) and in auto and in marine traffic control systems (I have limited knowledge), there are a common set of concepts, called the "clearance" and the "block" <-- primitives for traffic control systems. They apply in more than one domain (aviation's concepts were take directly from auto, train, and marine). These systems have all have common concepts, including relatively simply physical models. The primary differences involve the number of dimensions, the time constants (tau) associated with each, and some of the physical constraints. In this sense, making a turn in a car or plane is very similar, except for the time constants.
The human's interaction with such systems are different (e.g., power is controlled by the right foot in a car and (usually) by the right hand in a plane), but the operator's concepts are fairly similar.
[your statement] As a result, a driver, a pilot, a captain, and an engineer have totally different ways of thinking and reacting.
This just isn't so. The primary physical sensation is that the time constant is different, e.g., time delay and duration between control inputs and desired outcomes. A driver, a pilot, and a captain all navigate according to maps (mostly 2-D). For flying and driving, they are both largely 2-D navigation, with flying having the altitude added as a third dimension. Even autopilots are designed with this kind of 2-D thinking: 2-D autopilots (fairly common) or autopilots with vertical navigation (2D + vertical). For pilots, their first training involves tracking roads (following a rectangle) and largely navigating 2-D.
[your statement] Besides differences in motion, there are different kinds of signals to consider and different ways of planning a course and following it.
This statement isn't true. For example, the route from Washington, DC to New York City looks like (approximate directions):
driving: (1) travel to Beltway, (2) follow signs north to Baltimore/I-95, (2) travel north on I-95 for about 4 hours to New Jersey Turnpike exit 16E, (4) follow Route 3 east to Lincoln tunnel, (5) cross Lincoln Tunnel
flying: (1) "direct" to "MITCH" (an intersection in the sky at N38 58.0'/W076 44.5'), (2) fly "V123" (an airway) northeast to "PROUD" intersection (an intersection in the sky over southwest Brooklyn), (3) "direct" to LaGuardia
Note that the planning for driving and flying is fairly similar (for flying, you'd need to select an appropriate altitude, too). In fact, the "airways" and "jet routes" in the sky are very much like the Federal Highways (e.g., US Route 1) and the interstate highway system.
So in many ways, your illustration on driving, flying, etc., does not reflect the reality of these activities and systems.
[Illustration #3 from John Sowa's position paper:] Natural languages can express knowledge about any topic in any domain. But that does not make them domain independent. The syntax of language and the constraints at the level of case frames are largely domain independent, but the meaning of each word is highly dependent on the domain. As an example, consider the following four sentences:
Tom supported the tomato plant with a stick.
Tom supported his daughter with $8,000 per year.
Tom supported his father with a decisive argument.
Tom supported his partner with a bid of 3 spades.
These sentences all use the verb support in the same syntactic pattern:
A person supported NP1 with NP2.
Yet each use of the verb can only be understood with respect to a particular subject matter or domain of discourse: physical structures, financial arrangements, intellectual debate, or the game of bridge. ...
When I go to "dictionary.com" and look up "support", I get the following definitions (I just grabbed the first listing):
1. To bear the weight of, especially from below.
2. To hold in position so as to keep from falling, sinking, or slipping.
3. To be capable of bearing; withstand: "His flaw'd heart... too weak the conflict to support" (Shakespeare).
4. To keep from weakening or failing; strengthen: The letter supported him in his grief.
5. To provide for or maintain, by supplying with money or necessities.
6. To furnish corroborating evidence for: New facts supported her story.
7.
a. To aid the cause, policy, or interests of: supported her in her election campaign.
b. To argue in favor of; advocate: supported lower taxes.
8. To endure; tolerate: "At supper there was such a conflux of company that I could scarcely support the tumult" (Samuel Johnson).
9. To act in a secondary or subordinate role to (a leading performer).
These definitions cover the main meanings in your illustration. Certainly, there are subtleties to the use of "support", but they are no different than the context-specific meanings of the addition operator in any of the languages in your first illustration.
Discovering that the use of a token (e.g., addition operator or verb "support") that has a context-specific meaning in various contexts (e.g., syntaxes that produce context-specific meanings) that produces "sentences" with different meanings of the token <-- is not a surprising conclusion.
However, the existence of context-specific meanings does not speak for or against a "monolithic ontology". The concern about context-specific meanings might suggest that we need to understand something about "context" (what it is, how to describe it, its effects on things, etc.), but is a completely separate issue from "monolithic" vs. "modular".
In conclusion, all the illustrations and examples you've pointed to are faulty (e.g., programming languages and planes/trains/cars) or have little applicability (e.g., the 1971 article on programming design, your own position paper in 1991). The conclusions you draw from these sources are a bit of a stretch (e.g., how to divide into modules). None of these references make strong points on "monolithic ontologies".
Although I've given a rebuttal to your points, a main point of this E-mail (in the middle, above) might have gotten lost, so I've repeated it below
-FF
------------------------------------------------------------
[In reponse to John's complaint that the SUMO developers are just writing "code".]
It seems to me that the SUMO developers are writing standards wording, which someone has to do. I agree that there should be consistency, coherence, etc. ... this is why I suggested developing a "criteria" paper.
Within the standards process, we need to suggest better wording if we don't like the current wording. What are your suggestions? [John,] I really think you should try to write some standards words and contribute it to the SUO group.
For example, if you believe that certain axioms should be part of SUO, then how will you express them? I guess one can use natural language, but I think most of us would agree that code-like notations (e.g., KIF or KIF-like) can be concise and precise. So if you want axioms in SUO, but don't like code-like notations, then what do you propose? (FYI, CGs are like KIF; I'd consider CGs code-like; and I'd definitely prefer KIF over CGs because KIF seems to be better defined.)
If you don't want people volunteering time to contribute axioms, then how do you see us getting to a SUO standard?
What wording do you propose? (You [John Sowa] respond to me via E-mail, but don't suggest specific standards wording. I'll like to see your proposal for specific standards wording.)
------------------------------------------------------------
-----------------------------------------------------------------------
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards, products, services for the Global Information Infrastructure