Dear Ed,
I see that you are missing the point that Chris is trying to
make, which I (having talked about it with Chris on many
occassions) am comfortable I do understand. So let me see if
I can shed some light, or at least dispel some misunderstandings
of what Chris means by "Fruitfulness".
Chris Partridge wrote:
Among philosophers of science, I believe that the notion of
fruitfulness is
reasonably well established. Examples of it would be
applications of a
theory to things that the progenitor had no conception of
when he or she put
the theory forward. There are lots of quoted examples from
Newton's and
Einstein's work. There is also a lot of material on the web
(and ones local
library), if one has time to research it. I understand that
among many
working scientists fruitfulness in this sense is regarded
as a key test of
whether a theory is good/useful or not - so at least some
people hold it in
high regard.
But surely this is always in hindsight. Mathematicians and
physicists,
like software engineers, have some sense of "elegance" in
developing a
new theory, but elegance doesn't guarantee fruitfulness. 150 years
later, we can say that simple atomic theory was fruitful,
even though we
now know that simple atomic theory was a vast oversimplification of
atomic physics. OTOH, plate tectonics was rejected for 50
years, until
we were able to make enough reliable seismic measurements to
see that it
actually explained them -- in a sense, it was experimentally
validated.
MW: I think you are right to link elegance with fruitfulness.
I also think that Chris has not pointed out that he is using
fruitfulness in an analogous way to the way it would be used
in science, in the way that he applies it to analysis and
design (and hence to ontology). Specifically, fruitfulness in
software design is something that can be deliberately sought,
and you can measure that you are achieving it when, for example,
your code base falls, whilst your functionality rises (a result
of increased reuse). This is just the result that 42 SBS (where
Chris is currently working) have been experiencing.
At the other end of the spectrum, we have Lee De Forest, who fiddled
around with vacuum tube arrangements until he found one that did a
better job of picking up radio waves than Marconi's device. It was a
very fruitful invention, even though it was founded on very
little, and
mostly erroneous, understanding of the actual phenomenon.
MW: Well not in the sense that Chris means. This is just serendipity.
Fruitfulness
isn't restricted to carefully developed theories. 10 years
later, Edwin
Armstrong developed a theory that explained how the device actually
functioned, and went on to make much better ones, but (patent
disputes
aside) he started from De Forest's accidental insight. Many
assert that
Armstrong's work is what made De Forest's "audion tube" fruitful, but
the value of a theory or device to the later work of others is how we
define "fruitful".
MW: Again. Another example of what Chris does not mean by fruitfull.
We really do need the Lewis Carol principle of meaning here.
What we are talking about in this forum is design, not prophecy. An
engineer designs a device to perform a particular function,
to be "fit
for a purpose". A scientist devises a theory to be
consistent with all
the knowledge s/he has and to explain/predict a particular set of
phenomena (i.e., to be fit for those purposes). Similarly, we can
design an ontology to be consistent with all the knowledge we
have and
to be fit for a set of known purposes. Any fruitfulness
beyond that is
serendipity, in all cases.
MW: No. Here I strongly disagree with you. There are approaches to
design that allow more fruitfulness than others. Ironically, since
he also seems to be arguing against fruitfulness, a good example came
from Pat H. in one of his reponses to Pat C. in time ontologies. He
was proposing that a good approach for a shared ontology was one that
did not make a commitment (amongst other things) to whether time
was continuous or discrete, because this allowed more possibilities.
This is exactly an example of fruitful design, and fruitfulness in
design is about opening up possibilities, rather than closing them
down. I'm sure we have all seen the opposite of this, when some
useful possibility was deliberately prevented, because it was not part
of the stated requirements.
And it is probably fair to say that
fruitfulness will be a function of:
(a) the quality and extent of the knowledge we had at the outset
(b) the insight we had that generated the design/theory/ontology
(c) the acceptance and use of the design/theory/ontology by others,
whether purposefully, grudgingly, or unwittingly.
MW: Yes, I think this is all true.
One designs for fitness to a set of known purposes, not for potential
"fruitfulness". (It is my impression that Matthew and Paola almost
agreed to that.)
MW: Well not me at least. Yes of course fitness for purpose is the
minimum requirement, and you cannot be fruitful without being fit for
purpose. But fruitfulness is about how you achieve fitness for purpose,
and usually fruitfulness need be no more expensive, and may well
be cheaper than mere fitnes for purpose.
I have seen a number of instances of persons who design a theory to
support what they understand well and also phenomena for
which they have
some awareness but no expertise. Without exception, those
theories have
been useless or counterproductive for the extended phenomena. (What
inevitably happens is that the proponents force the square
pegs in the
extended domain into the round holes in the theory, thereby divorcing
the theoretical results from the realities.) My former
mentor, the late
Dr. Selden Stewart, described this effort to achieve
fruitfulness beyond
one's knowledge domain as "the seductiveness of simple
cases", a form of
"false induction": the theory works for lots of simple cases
that we are
now familiar with; therefore it must work for more complex
cases that we
haven't studied so well. The examples include the unix (v5) model of
peripheral stores, reactive hierarchical control, object modeling,
reusable components, orchestrated processes, and several
bizarre ideas
that have wrecked adoption of what might have been worthwhile
standards.
MW: Well, the fact that things can be done badly, doesn't mean
that they can't be done well.
So I would in fact caution *against* attempts to design for
"fruitfulness" beyond one's domain of expertise.
MW: I agree, though in systems design you also have the expertise
of those users involved in what you are doing, not just your own
knowledge of the business. Indeed, your domain of expertise is
analsis of requirements, and it is your approach and expertise
in that that will lead to fruitfulness, if indeed you have the
skills.
-Ed
P.S. In 1994, the UK editor of ISO 10303-11 (the information modeling
language EXPRESS) announced the results of a survey of needs
for version
2, and the set was so diverse in direction that I asked
whether he had
in mind one project or two.
MW: Yes, I remember being similarly startled at the time.
The editor said, "one, of
course", and the
senior U.S. delegate (Peter Wilson, of Boeing) said, "Oh, I
was sure you
would say two." A German delegate asked why Peter thought
there should
be two projects, and Peter answered, "Because I have the grey hair,
that's why." (And OBTW, 7 years later, the "one" project failed.)
MW: There is of course an edition 2 now, but it is for a very
much reduced scope.
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx