At 8:33 PM +0000 1/24/08, Chris Partridge wrote:
I have cut out some irrelevant
>>I think this is where
ontology (as a picture of reality comes
don't follow. Why would it come in here more than in
>software? Surely you aren't thinking of ontologies as new
>theories (are you??)
There is a long tradition of
regarding computer systems as theories.
As *scientific* theories?
MW: No. It was you that introduced the word
give you the quotes if you
Jonathon Lowe (a philosopher I recall you meeting) has a
definition of ontology as "the set of things whose existence is
by a particular theory or system of thought." (E. J. Lowe,
Companion to Philosophy)
He is clearly using the word in its philosophical sense, not its IT
sense. Nobody in this forum is doing philosophical ontology.
MW: How would you distiguish his use of the word "theory" from
the meaning that you would ascribe to it in a computing
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"
Im not sure what that means, but its certainly not ontology as in
MW: In what way is it different? In what sense is the set of things that
a system will let you hold information about not its ontology? If it is not its
ontology, what is it?
reflected upon this, what we realised is that we had tried
>>succeeded to an extent) in capturing the main features of
>>- and that the new (unrecognised)
situations were just (very) unfamiliar
>>combinations of familiar
>You were lucky!
The issue for us was
that this became a regular feature, so it seemed to be
I meant, you were lucky that you only had to go around the knowledge
extraction loop once.
MW: Perhaps, but it might also be skill in the knowledge extraction
process that enables the "fruitfulness" that Chris refers
>That seems on the face of it to be self-contradictory. Isnt it
>much the definition of 'unforseen' that one cannot plan for it
>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
saying that the financial markets are volatile, and new instruments
going to arise (whose details we do not know) - and how we plan for
some level, we are saying that we cannot foresee what is going to
Right. So how is it possible to plan for something that you cannot
forsee, other than in a general sense trying to stay alert?
MW: After your response to Pat C advising him to favour an ontology of
time that did not make a commitment to a continuous or granular view of time,
exactly the kind of fruitfuness in design Chris and I are advocating, I am
surprised that you would say that. Fruitfulness in design, for me, has a lot to
do with not closing off possibilities unnecessarily. This is not so much a
matter of forseeing future requirements, as designing, in a way that allows what
>>One way of doing this is to try and make
reflect what is actually happening reasonably accurately
Surely that is exactly what one should not do, in order to be able
handle unforseen situations. That strategy will lock in the way
are at the time the system is designed, not the way that
>> - 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
want details you can read the book. What is immeasurable or subjective
I need to read the book, obviously, but I suspect we are at cross
purposes. I cannot even imagine what would be a simple test of success at
solving an unforseen problem. Unforseen by who, when? Suppose it turns out to
be able to do something unforseen, but the designer then tells you they had in
fact forseen that and planned for it. Who is to contradict them?
MW: Yes, I think you are at cross purposes. I suspect that one of the problems here is that
you would take what I would call fruitful design as obvious, but it is not so
frequently practised. A good test of fruitful design is that it does not
make any statements that are not true under all circumstances (in any context to
bring together two threads). It is precisly this that makes a piece of ontology
portable, reusable, and hence fruitful.
But in any case, why has this got anything much to do with ontology
design? Do you feel that ontologies should be designed for unforseen things
more than other artifacts?
MW: I think you are getting too hung up on this unforseen
thing. It is not the main
point, reusability, flexibility, and extensibility are the results of
fruitfulness, whether or not you can forsee all the consequences that this might
bring. The kind of behaviours that lead to this are not placing constraints at a
higher level in the ontology than they truly reside, just because
other parts of a larger ontology are not part of the requirements this
time - one of John Sowa's hobby horses, and another way of saying what I
said above, about making statements that are true in all
Reference Data Architecture and
Shell International Petroleum Company Limited
in England and Wales
Registered number: 621148
Registered office: Shell
Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Mobile: +44
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 (01)