I have cut out some irrelevant stuff.
>>So I will try and give you some from computer systems. There are very
>>examples which start to they make the point but do not get to the heart of
>>A colleague (many years ago) was selling a bespoke system to BT (I might
>>wrong about the client). He asked them what currency they wanted the
>>to use. They said GBP. He did not believe them, so he included currency as
>>variable rather than GBP as a constant. Six months later, he was able to
>>charge them a significant amount of money to enable a few more currencies.
>Is this really fruitfulness in the same sense? Seems quite a
>different notion to me, almost the inverse: the generality was built
>in, not discovered later. (02)
If you look to the operational dataset, then there was no example of more
than one currency. So from that perspective, it had not been used. But this
is not the key point.
>>He did not feel obliged to mention that this took next to no work.
>>The inverse of this is a joke this side of the Atlantic, that US computer
>>systems seem to assume that there is only one currency - USD.
>>I think we can all come up with examples like this. What these lack though
>>is the important ingredient - that the functionality was completely
>>I think this is where ontology (as a picture of reality comes
>I don't follow. Why would it come in here more than in designing
>software? Surely you aren't thinking of ontologies as new scientific
>theories (are you??) (03)
There is a long tradition of regarding computer systems as theories. I will
give you the quotes if you wish. (04)
Jonathon Lowe (a philosopher I recall you meeting) has a technical
definition of ontology as "the set of things whose existence is acknowledged
by a particular theory or system of thought." (E. J. Lowe, The Oxford
Companion to Philosophy) (05)
Taking these two points together, one can regards a computer system's
ontology as (roughly) "the set of things whose existence is acknowledged by
a particular computer system" (06)
>>In the preface of my book - Business Objects - I note "Furthermore, as the
>>users became more familiar with their systems, something remarkable begins
>>to happen. The systems seem to have captured the essence of the business.
>>We realised this when we found them being used to handle areas that had
>>been envisaged when we built the business model. For instance, on one
>>project the users found that their re-engineered securities back-office
>>system could already handle new financial instruments and situations that
>>no-one had thought of when the system was built."
>>What happen here was that we were working with corporate actions, which
>>because of tax laws, are quite convoluted. After the system was
>>we went down to the users to see how things were going. They explained to
>>use that it was handling extremely complicated situations really well -
>>described the details. We then got annoyed with them because they had not
>>described these particular situations when we were building the ontology
>Yes, this is familiar from 'expert systems' and knowledge extraction
>lore. One needs to iterate the process of model description and
>>We calmed down when we realised there was not a problem.
>>When we reflected upon this, what we realised is that we had tried (and
>>succeeded to an extent) in capturing the main features of corporate
>>- and that the new (unrecognised) situations were just (very) unfamiliar
>>combinations of familiar features.
>You were lucky!
The issue for us was that this became a regular feature, so it seemed to be
more than luck. (08)
>>In our work on re-engineering legacy systems, we find we can monitor this
>>(this is also described in the book). One re-engineers the legacy system
>>chunks, if patterns/features that arise in one chunk are fruitful, they
>>up in unfamiliar ways as you use them in successive chunks.
>>On the face of it, it seems right to say that a system needs to be fit for
>>particular purpose (and only that purpose). However, this assumes that we
>>can define the purpose in the detail needed to implement it. The history
>>most computer systems (probably most systems) would tend to show that this
>>assumption is false. In that case, the design needs to be, as far as it
>>be, for the unforeseen situations.
>That seems on the face of it to be self-contradictory. Isnt it pretty
>much the definition of 'unforseen' that one cannot plan for it ahead
>of time, since it is invisible?
I think there is a difference between saying that we can foresee that we are
going to do USD/GBP currency exchanges - and how we plan for that in a
And saying that the financial markets are volatile, and new instruments are
going to arise (whose details we do not know) - and how we plan for that. At
some level, we are saying that we cannot foresee what is going to happen. (010)
>>One way of doing this is to try and make
>>the design reflect what is actually happening reasonably accurately
>?? Surely that is exactly what one should not do, in order to be able
>to handle unforseen situations. That strategy will lock in the way
>things are at the time the system is designed, not the way that
>things might become later.
>> - one
>>way of testing this is to see how fruitful the design is.
>How does one set out to do that? This sounds about as clear as
>testing a design for 'elegance' or some other unmeasurable subjective
I do not understand. The test is reasonably simple and has clear results. If
you want details you can read the book. What is immeasurable or subjective
about it? (012)
>>Has this been concrete enough for you?
>It gets the general idea across admirably, but Im still left with an
>uneasy feeling that this word "fruitfulness" is jargon without any
>precise enough meaning to be actually used to help the design
>process. It seems to have been defined, in fact, so that it can't be
>so used. Since it only happens unexpectedly, how can one plan for it
>I have to say, this entire discussion seems to me like a huge
>timewaster. We are having enough trouble with real ontology
>engineering issues. Do we really need to get lost in debating
>whatever this is about?
>>>From: Pat Hayes [mailto:phayes@xxxxxxx]
>>>Sent: 24 January 2008 16:44
>>>Cc: Chris Partridge
>>>Subject: Re: [ontolog-forum] Time representation
>>>At 9:04 AM +0000 1/24/08, Chris Partridge wrote:
>>>>....It seems to me when designing computer
>>>>systems (and the ontologies to support them) that we need to be
>>>>the issue of fruitfulness.
>>>Chris, I have absolutely no idea what you are talking about. Can you
>>>make it a little more concrete?
>>>IHMC (850)434 8903 or (650)494 3973 home
>>>40 South Alcaniz St. (850)202 4416 office
>>>Pensacola (850)202 4440 fax
>>>FL 32502 (850)291 0667 cell
>>>No virus found in this incoming message.
>>>Checked by AVG Free Edition.
>>>Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date:
>>No virus found in this outgoing message.
>>Checked by AVG Free Edition.
>>Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date:
>IHMC (850)434 8903 or (650)494 3973 home
>40 South Alcaniz St. (850)202 4416 office
>Pensacola (850)202 4440 fax
>FL 32502 (850)291 0667 cell
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date:
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
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (015)