RE: SUO: Re: Ballot Comment - 3D versus 4D.

["Horn, Graham" <graham.horn@aihw.gov.au>]

Thanks John, 
	.		Further comments interspersed below, prefaced  "GH2>
".



Cheers   				Graham Horn
National Data Standards Unit
Australian Institute of Health and Welfare 
================================================
Phone:      	02.6244.1094  
Fax:          	02.6244.1199  
E­mail:    	Graham.Horn@aihw.gov.au <mailto:graham.horn@aihw.gov.au>


-----Original Message-----
From:	John F. Sowa [mailto:sowa@bestweb.net]
Sent:	Thursday, 30 August 2001 2:33
To:	Horn, Graham
Cc:	Chris Partridge; Adam Pease; standard-upper-ontology@ieee.org; West,
Matthew R SITI-GREA-UK; 'pat hayes'
Subject:	Re: SUO: Re: Ballot Comment - 3D versus 4D.

Graham,

I agree with your comments, and I'd to make some further observations:

> GH> I guess this approaches the
> heart of the distinction with my own
> perspective. I believe the developers
> should be making a flexible structure
> that accommodates both perspectives, 
> and works with the appropriate one for
> the circumstances in question at any
> particular instance.
 
> GH> The underlying difference with
> this approach is that most of the
> ontology development seems to want
> to concentrate on a single conceptual
> dimension, meaning that the
> perspective on any particular item is to
> be rigidly fixed (eg. We may decide to
> always treat cars as 3­D, but people as
> 4­D). I don't think this will ever achieve
> the universality we want. That's why I
> am calling for a more complicated
> approach that has "depth", and
> accommodates more precisely to the
> conceptual circumstances and
> requirements of any particular task.

I endorse Graham's view of the requirements:

 1. The first key phrase in Graham's note is
    "a flexible structure that accommodates
    both perspectives, and works with the
    appropriate one for the circumstances in
    question at any particular instance."

    My only recommendation is to replace the word "both" with "all".

GH2>	Agreed. 

 2. I agree with Graham's complaint that
    the SUMO developers "want to concentrate
    on a single conceptual dimension, meaning
    that the perspective on any particular item is
    to be rigidly fixed."

    A single rigid perspective on anything is
    unrealistic.  It cannot accommodate existing
    systems, which have been developed from
    many different perspectives, and it can never
    accommodate any future view that differs
    from what the SUMO developers intended.
    Only God could have the omniscience to
    make such an approach work, and He wisely
    gave us a choice.

 3. I wholeheartedly endorse Graham's conclusion:
    "I am calling for a more complicated approach
    that has "depth", and accommodates more
    precisely to the conceptual circumstances and
    requirements of any particular task.

    My only suggestion is to replace the word
    "complicated" with "flexible".   For the
    reasons discussed below, I believe that the
    current SUMO approach is vastly more
    complicated than any modular approach
    could ever be.

GH2>	Happy with this, except that I also wished to also get over the
point that flexible systems need often, though not always, to be more
complex to implement in code, etc. 

Following is an excerpt from a paper by E. W. Dijkstra, entitled "On our
inability to do much."  He was writing about the need to break programs into
smaller, more manageable modules, but his comments apply equally well (if
not more so) to ontology.  I found this excerpt at the web site, which
discusses several other contributors on the same theme, including Herb
Simon, Fred Brooks, Tony Hoare, and others.  Following is the reference:

 
http://www.scenarioplus.org.uk/handwritten/historical/historical_text.htm

After the excerpt by Dijkstra, I also quote Simon's example about the two
watchmakers.  The monolithic SUMO approach is doomed for exactly the same
reasons as the monolithic watchmaker.

John Sowa
_______________________________________________________________________

From _Notes on Structured Programming_ by E.W.Dijkstra:

ON OUR INABILITY TO DO MUCH

I am faced with a basic problem of presentation.  What I am really concerned
about is the composition of large programs, the text of which may be, say,
of the same size as the whole text of this chapter.  Also I have to include
examples to illustrate the various techniques.  For practical reasons, the
demonstration programs must be small, many times smaller than the "life-size
programs" I have in mind.  My basic problem is that precisely this
difference in scale is one of the major sources of our difficulties in
programming!

It would be very nice if I could illustrate the various techniques with
small demonstration programs and could conclude with "..and when faced with
a program a thousand times as large, you compose it in the same way."  This
common educational device, however, would be self-defeating as one of my
central themes will be that any two things that differ in some respect by a
factor of already a hundred or more, are utterly incomparable.  History has
shown that this truth is very hard to believe.  Apparently we are too much
trained to disregard differences in scale, to treat them as "gradual
differences that are not essential". We tell ourselves that what we can do
once, we can also do twice and by induction we fool ourselves into believing
that we can do it as many times as needed, but this is just not true!  A
factor of a thousand is already far beyond our powers of imagination!

Let me give you [an] example to rub this in.  A one-year old child will
crawl on all fours with a speed of, say, one mile per hour.  But a speed of
a thousand miles per hour is that of a supersonic jet.  Considered as
objects with moving ability the child and the jet are incomparable, for
whatever one can do the other cannot and vice versa.

To complicate matters still further, problems of size do not only cause me
problems of presentation, but they lie at the heart of the subject:
widespread underestimation of the specific difficulties of size seems one of
the major underlying causes of the current software failure. To all this I
can see only one answer, viz. to treat problems of size as explicitly as
possible...

To start with, we have the "size" of the computation, i.e. the amount of
information and the number of operations involved in it.  It is essential
that this size is large, for if it were really small, it would be easier not
to use the computer at all and to do it by hand.  The automatic computer
owes its right to exist, its usefulness, precisely to its ability to perform
large computations where we humans cannot.  We want the computer to do what
we could never do ourselves and the power of present-day machinery is such
that even small computations are by their very size already far beyond the
powers of our unaided imagination.

________________________________________________________________________

The Evolution of Complex Systems,

From Herbert A. Simon, "The Architecture of Complexity:  Hierarchic
Systems," _Proceedings of the American Philosophical Society_, 106, Dec
1962, 467-482.

Let me introduce the topic of evolution with a parable.  There once were two
watchmakers, named Hora and Tempus, who manufactured very fine watches.
Both of them were highly regarded, and the phones in their workshops rang
frequently - new customers were constantly calling them. However, Hora
prospered, while Tempus became poorer and poorer and finally lost his shop.
What was the reason?

The watches the men made consisted of about 1,000 parts each.  Tempus had so
constructed his that if he had one partly assembled and had to put it down -
to answer the phone, say - it immediately fell to pieces and had to be
reassembled from the elements.  The better the customers liked his watches,
the more they phoned him and the more difficult it became for him to find
enough uninterrupted time to finish a watch.

The watches that Hora made were no less complex than those of Tempus. But he
had designed them so that he could put together subassemblies of about ten
elements each.  Ten of these subassemblies, again, could be put together
into a larger subassembly; and a system of ten of the latter subassemblies
constituted the whole watch.  Hence, when Hora had to put down a partly
assembled watch to answer the phone, he lost only a small part of his work,
and he assembled his watches in only a fraction of the man-hours it took
Tempus'.

It is rather easy to make a quantitative analysis of the relative difficulty
of the tasks of Tempus and Hora:  suppose the probability that an
interruption will occur, while a part is being added to an incomplete
assembly, is p. Then the probability that Tempus can complete a watch he has
started without interruption is (1 - p)1000 - a very small number unless p
is 0.001 or less.  Each interruption will cost on the average the time to
assemble 111 parts (the expected number assembled before interruption).  On
the other hand, Hora has to complete 111 subassemblies of ten parts each.
The probability that he will not be interrupted while completing any one of
these is (1 - p)10, and each interruption will cost only about the time
required to assemble five parts.

Now if p is about 0.01 - that is, there is one chance in a hundred that
either watchmaker will be interrupted while adding any one part to an
assembly - then a straightforward calculation shows that it will take Tempus
on the average about four thousand times as long to assemble a watch as
Hora.