Do agree that top down is more important if you know enough, but bottom
up can be more important if for example the design is for an area that
is very new, very rapidly changing, or for very diverse and distributed
applciations I think. (01)
(poss relates to the current debate about ontologies and folksonomies,
and to the Web 2.0 approach to designing shared knowledgebases where one
size won't fit all). (02)
matthew.west@xxxxxxxxx wrote:
> Dear Jenny,
>
> Actually I think it is most important in top down design, in that
> design for fruitfulness is about how you choose the theoretical
> principles to apply, and where. Biology can be more hit and miss, if
> you try enough times, eventually you get it right.
>
>
> Regards
>
> Matthew West
> Reference Data Architecture and Standards Manager
> Shell International Petroleum Company Limited
> Registered in England and Wales
> Registered number: 621148
> Registered office: Shell Centre, London SE1 7NA, United Kingdom
>
> Tel: +44 20 7934 4490 Mobile: +44 7796 336538
> Email: matthew.west@xxxxxxxxx
> http://www.shell.com <http://www.shell.com/>
> http://www.matthew-west.org.uk/
>
> -----Original Message-----
> *From:* ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]*On Behalf Of *jure2
> *Sent:* 25 January 2008 10:33
> *To:* [ontolog-forum]
> *Subject:* Re: [ontolog-forum] Time representation
>
> 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
>
> (03)
_________________________________________________________________
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 (04)
|