[Top] [All Lists]

Re: [ontolog-forum] Time representation

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Chris Partridge" <mail@xxxxxxxxxxxxxxxxxx>
Date: Thu, 24 Jan 2008 20:16:34 -0000
Message-id: <003601c85ec6$04ec9c10$0400a8c0@POID7204>
>Chris Partridge wrote:
>> Among philosophers of science, I believe that the notion of fruitfulness
>> 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
>> 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
>> 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
>> whether a theory is good/useful or not - so at least some people hold it
>> 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.    (01)

Is the argument here that fruitfulness can ONLY be recognised in hindsight?
Is this an empirical or logical fact?
If empirical, where is this proof?
Surely your position begs the question.    (02)

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

For practicing software engineers, there is probably a need to clarify the
semantics of requirements definition here. 
It is true for most commercial systems that their fitness for purpose would
be increased significantly if they were designed to meet the unspecified
requirements that will arise during their lifetime. 
However, this would not be regarded as a practical requirement as it could
not be cashed out directly in a test case. 
So could something like this be included in a 'fitness for purpose'
My guess is that for many practicing software engineers this would be too
woolly to be regarded as a purpose (in your parlance not a sufficiently
'known' purpose).
Does this make it irrelevant? I am not sure why it should.    (04)

As you say above - "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". From my engineer's perspective, it sounds as
if the scientist is trying to not skew his/her theory with a particular
purpose. The interesting question, for me, is under what circumstances does
a more scientific approach, by being more fruitful, turn out to be more
likely to give the customer a system that is more 'fit for purpose'. This
will then help to guide practice.    (05)

>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.)
>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.
>  So I would in fact caution *against* attempts to design for
>"fruitfulness" beyond one's domain of expertise.
>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.  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.)
>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
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date:
>23/01/2008 17:47
>    (06)

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date: 23/01/2008
17:47    (07)

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

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