[Top] [All Lists]

Re: [ontolog-forum] Time representation

To: <ontolog-forum@xxxxxxxxxxxxxxxx>
From: <matthew.west@xxxxxxxxx>
Date: Fri, 25 Jan 2008 09:22:41 -0000
Message-id: <808637A57BC3454FA660801A3995FA8F06455368@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Dear Ed,    (01)

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".    (02)

> 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.    (03)

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.    (04)

> 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.      (05)

MW: Well not in the sense that Chris means. This is just serendipity.    (06)

> 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".    (07)

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.      (08)

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.    (09)

> 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.    (010)

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.)    (011)

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.     (012)

MW: Well, the fact that things can be done badly, doesn't mean
that they can't be done well.    (013)

>   So I would in fact caution *against* attempts to design for 
> "fruitfulness" beyond one's domain of expertise.    (014)

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.    (015)

> -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.      (016)

MW: Yes, I remember being similarly startled at the time.    (017)

> 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.)    (018)

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
>     (019)

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    (020)

<Prev in Thread] Current Thread [Next in Thread>