ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Time representation

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: jure2 <jure2@xxxxxxxxxxxx>
Date: Fri, 25 Jan 2008 10:32:39 +0000
Message-id: <4799BAC7.4000208@xxxxxxxxxxxx>
Perhaps 'fruitfulness' reflects design that is shaped by feedback (as in distributed biological systems and complex systems) as opposed to design that is shaped by theoretical principles (elegant top down applications of principles)

It strikes me that both approaches inform each other in practice.

Jumping in on basis of the last post - sorry if missing the point of earlier eachanges :-)

Jenny Ure

matthew.west@xxxxxxxxx wrote:
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
 
  


_________________________________________________________________
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    (01)

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