Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SUO: RE: RE: Organization




Martin,

I generally agree with the remarks you made.  In particular, I would
like to comment on the following paragraph:

> It may help to recognize that every SUO
> term will have some precise boundaries on what it does or does not mean
> implicit from its SUO KIF definition and these precise boundaries are bound
> to include or exclude some meanings that are associated with the natural
> language words chosen.  Put it another way, if we replaced all the English
> terms in the EO with "EO001, EO002, .....  EO103", the semantics of the KIF
> would be precisely the same, and EO042 including Position would be a lot
> less likely to be counterintuitive.  On the other hand, I suspect the EO
> would become totally unreadable and useless.

The basic point is that the labels on the types and relations in any
formal theory are never exact synonyms for the words in any natural
language.  At best, the labels can be reminders, but at worst, they
are traps for the unwary.  The mappings from language(s) to theories
must be done, but the words of any language must be kept distinct
from the labels of the formal entities.

I also like Tony Hoare's comment, which you used as your ending
quotation:

"There are two ways of constructing a software design.  One is to make
it so simple that there are obviously no deficiencies; the other is
to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult."

I would point out that SUMO is currently taking the second approach.

Following is another of Hoare's quotations, which also applies to SUMO:

"A lack of clarity in specification is one of the surest signs of
a deficiency in the program it describes, and the two faults must be
removed simultaneously before the project is embarked upon."

Those quotations come from Hoare's Turing Award talk, entitled
"The Emperor's Old Clothes".  Following is a longer excerpt about the
failure of ALGOL 68.  It is a good lesson for anyone who is working
on a standards effort:

   http://cs.ru.ac.za/homes/cspt/hoare.htm

John Sowa