Re: SUO: Modularity
> >[FF] In this area of engineering (mostly software engineering),
>modularity was introduced in the late 1960's through the 1970's....
>
>[JS] 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.
In any reasonable sense, one can probably date the introduction of
modularity in the modern sense to the mid-19th century when the
advent of reasonably precise machine tools made it possible to
manufacture complex machinery with interchangeable parts (marine
tackle - Brunel; guns - Colt; clocks - Jerome). Although the
industrial revolution is often equated with the development of new
power sources, the industrial historian T. Rolt makes out a very
convincing case that it was precision in toolmaking, yielding
repeatability of manufacture, yielding modularity of parts, that
really marked the beginning of the modern industrial age, and has
been the leading edge of manufacturing processes ever since. The
modern automobile engine was made possible by the invention of a
centerless precision grinder, for example. Certainly the funding
agencies in those days understood this; they gave Reynolds $5000 for
one very accurate screw thread, which was then used to calibrate a
line of travelling-carriage lathes which give the English navy steam
propulsion plants with interchangeable parts.
> >[FF]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.....
>
>[JS]Wrong! That is not the lesson Freddy B. was trying to get across.
Right, that is a completely different issue.
...
>.....
> >[FF] The main reason not to "go modular" is coherency and consistency,
On the face of it, that seems an incredibly silly remark. On those
grounds, all APIs should be scrapped, and all process communications
should be re-negotiated on an ad-hoc basis, in the interest of
coherency and consistency.
....
>
>>[FF] 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**....
>
>[JS]No! The upper ontology is *not* the high-level design.
Correct. This is just a pun on 'high-level'
.....
> >[FF] 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.
Another important point about dictionaries is that they record
decisions taken by probably the largest 'user communities' ever
assembled, viz. entire cultures and civilisations comprising usually
millions of native speakers of a language. What the SUO is doing is
more like trying to invent a language in a situation where no
language has ever yet been used by anyone.
>.......
> >[FF] - 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.
I also agree. There seems to ba a major disconnect here in the entire
SUO activity. I have no clear idea what kind of software conformance
is envisioned. Just focus on the concept classification heirarchy,
for example, and leave the axioms out of the picture; what kind of
conformance would be expected? That any reasoner use this as its
classification heirarchy? Of part of its heirarchy? That it be
consistent with the program's heirarchy?(Relative to the semantics of
what formalism?) What about other kinds of software? Could an API
fail to conform to an ontology standard, for example? (How?) Could a
web-based ontology engine be said to conform or not to the SUO? How
would one make the determination that it did or did not?
Pat Hayes
--
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
phayes@ai.uwf.edu
http://www.coginst.uwf.edu/~phayes