At 5:22 PM +0000 1/24/08, Chris Partridge wrote:
>Pat,
>
>I assume that you do not want me to explain fruitfulness as used in the
>philosophy of science - there was a pointer in my original email. You will
>find concrete examples galore from science there. (01)
Yes, subsequent emails clarified the idea, thanks. However, I think
its important for us to all agree that we aren't setting out to do
actual science in this forum. (02)
>So I will try and give you some from computer systems. There are very simple
>examples which start to they make the point but do not get to the heart of
>the matter.
>
>A colleague (many years ago) was selling a bespoke system to BT (I might be
>wrong about the client). He asked them what currency they wanted the system
>to use. They said GBP. He did not believe them, so he included currency as a
>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. (03)
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. (04)
>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
>unexpected. (05)
Quite. (06)
>I think this is where ontology (as a picture of reality comes
>in). (07)
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??) (08)
>
>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 not
>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 implemented
>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 - and
>described the details. We then got annoyed with them because they had not
>described these particular situations when we were building the ontology for
>the system. (09)
Yes, this is familiar from 'expert systems' and knowledge extraction
lore. One needs to iterate the process of model description and
critique. (010)
>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 actions
>- and that the new (unrecognised) situations were just (very) unfamiliar
>combinations of familiar features. (011)
You were lucky! (012)
>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 in
>chunks, if patterns/features that arise in one chunk are fruitful, they show
>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 a
>particular purpose (and only that purpose). However, this assumes that we
>can define the purpose in the detail needed to implement it. The history of
>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 can
>be, for the unforeseen situations. (013)
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? (014)
>One way of doing this is to try and make
>the design reflect what is actually happening reasonably accurately (015)
?? 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. (016)
> - one
>way of testing this is to see how fruitful the design is. (017)
How does one set out to do that? This sounds about as clear as
testing a design for 'elegance' or some other unmeasurable subjective
quality. (018)
>
>Has this been concrete enough for you? (019)
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
in advance? (020)
----
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? (021)
Pat (022)
>
>Regards,
>Chris
>
>>-----Original Message-----
>>From: Pat Hayes [mailto:phayes@xxxxxxx]
>>Sent: 24 January 2008 16:44
>>To: [ontolog-forum]
>>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 sensitive
>>to
>>>the issue of fruitfulness.
>>
>>Chris, I have absolutely no idea what you are talking about. Can you
>>make it a little more concrete?
>>
>>Pat Hayes
>>--
>>---------------------------------------------------------------------
>>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
>>phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>
>>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
>>
>
>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
> (023)
--
---------------------------------------------------------------------
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
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes (024)
_________________________________________________________________
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 (025)
|