Matt, (01)
Matthew West wrote: (02)
> 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. (03)
I agree that I don't understand. (04)
The first problem I see is that Chris didn't identify the "class" for
which "fruitful" is a possible property. You (all) clearly don't intend
it to apply to "thing" generally -- the meaning of "Abraham was
fruitful" is different. It apparently applies to "theory", but it is
not clear whether it applies to a "design" or a "device". (05)
> 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). (06)
I am not sure what kind of analogy is valid here. (07)
A "device" is intended to fulfill a set of functions, and therefore its
"design" (the abstract conception of the device) is "fit for its
purpose" if and only if it enables all of those functions to be
fulfilled (and exhibits no deleterious side effects). (08)
A scientific "theory" is intended to explain a set of observed phenomena
and predict others. It is "fit for its purpose" if and only if it
explains all of those phenomena in a consistent way. (09)
The "fruitfulness" of a design/device derives from an ability to support
functions which were not envisaged, or to support such functions with
minor additions or changes. If it was designed to support those
additional functions, then that was its initial purpose. That is why I
say that the fruitfulness of a design can only be observed in hindsight. (010)
The "fruitfulness" of a scientific theory derives from its ability to
explain or predict phenomena that were not part of the original scope of
observation, and are in some important way unlike the original
observations. And in a way similar to design, that expanded scope may
require consistent additions or minor changes to the original theory. (011)
So I do see analogy in the use of the terms "fit for purpose" and
"fruitful", but I also see important differences in the nature of the
underlying elephant. (012)
In my view, a software system is a "device" (a machine), or in the
abstract a "design" (for a machine). A software system is *not* a
theory. It follows that the development of software systems is an
"engineering" task, not a "scientific" task. (One needs the scientific
knowledge to best perform the engineering task, but the engineering task
is not to *develop* the knowledge, it is rather to *use* it in creating
the design.) If we disagree on this point, and it appears that we do,
we will be unable to communicate, or at best unable to reach anything
like consensus. (013)
Further, I would say that the design of an "IT ontology" is an effort to
capture knowledge in a way that makes is useful to a certain kind of
reasoning machine in fulfilling certain functions. It is an engineering
task. It is not about further developing the knowledge base itself, nor
is it about developing a theory for reasoning from it, and it is not
only about what that knowledge *is*. It is about what part of that
knowledge you *need* to perform the envisaged functions, and what part
of it can be expressed in a way that is useful to the reasoning machine.
That is, it is a part/component of a software device/system that
includes the reasoner. (014)
> MW: I think you are right to link elegance with fruitfulness. (015)
"Elegance" is about avoiding unnecessary limitations and making the
design clear and compartmental, so that it is easy to understand and
modify. It is clear that an "elegant" design is more likely to be
"fruitful", and that applies to "IT ontologies" as well. (016)
You can design a software device (and many other devices) to avoid
certain limitations that would not affect the target functionality, but
that doesn't make it more "fruitful". To make it "fruitful" you
actually have to have it used to perform a function that was not
envisaged. And to make the "elegance" significant, the new application
should not have been possible if those limitations were present. (017)
> Specifically, fruitfulness in
> software design is something that can be deliberately sought, (018)
I agree, but I don't think that explicitly seeking it provides any
likelihood of having it. The point of my examples was that "elegance"
is only a probabilistic predictor of "fruitfulness" -- many elegant
designs are not fruitful, and some fruitful designs are not elegant. (019)
In fact, as I said and exemplified, explicitly seeking "extended
applicability" or "elegance" has often proved to be misguided. (020)
> 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. (021)
I don't understand the reference, but I think I disagree entirely. (022)
When I initially build a software system, I can't measure its
fruitfulness. I can only measure its size, complexity, cost, and
fitness to the specified purpose -- its ability to carry out the
envisaged functions. 5 years later, when it is running with minimal
change, and is being used for projects not originally envisaged, and has
been extended to other projects with minimal further code development
and modification, I can see that it is fruitful. (023)
If I am *re-engineering* the code for a set of functions, some of which
were not initially envisaged in the forerunner system, I have a new
design project. I have a new set of target functions, off-the-shelf
capabilities and limitations, and I am designing a new system to support
those functions using those capabilities and within those limitations.
And yes, by careful re-design of some central modules, I can eliminate a
lot of code that was add-ons, work-arounds and patches to the original
code. The original code was underdesigned for what proved to be the
required functionality. But I'm not measuring "fruifulness" of the new
design; I am measuring a qualitative and quantitative improvement over
the old "design" (which was probably gradually emergent) for what is now
the complete set of purposes (and probably some new ones as well). And
in this new design project, I have many benefits from hindsight, and
other benefits from progress in the state of the practice, and I can
employ some foresight, but it will take 1-5 years to get a real measure
of "fruitfulness". (024)
Whether designing a system n years ago that would have proved to be more
"fruitful" required a tremendous amount of clairvoyance, or just
minimal awareness of the emerging state of the practice, or a more
competent architect, or just management acceptance of the real project
and its cost, is a separate issue. And whether the current situation is
improved in those ways is a related issue. "Fruitless" systems are
built for a variety of reasons, only some of which are under control of
the senior engineers. But only some senior engineers really know their
trade (the Peter Principle applies), and only some get functionality,
elegance and modularity in the right perspective. We now know enough to
get the first system design right the second time around, and with a
real expert at the helm we can do just that. The first real addition
to, or change from, the currently envisaged functionality, however, will
be the test of whether this system is really more "fruitful". (025)
> MW: We really do need the Lewis Carroll principle of meaning here. (026)
Indeed. Thank you, Humpty Dumpty. (027)
But Pat is right: When we are done with this discussion, will we have
added any useful insight to the problem of designing/developing "IT
ontologies"? (028)
My excuse for continuing this discussion is that we do need some kind of
guidelines for development of ontologies. We don't need to define
"elegant" or "fruitful". But we need to separate the ideas
- "ontology to be used for a particular project"
- "ontology to be used for several known and expected projects"
- "ontology to be published on the Web for general reference" (029)
In the first case, you know the reasoner, you know the specified
function set, and reuse and general validitiy are not high priorities.
(One of the Cyc problems was that the major funding source had some very
unusual knowledge concepts and concerns that resulted in some rather
special-purpose ontologies, and some unusual twists on general concepts.) (030)
In the second case, there is probably more than one reasoner and you
don't know all the functions. There you want to work on clear,
extendable general-purpose models at a level that incorporates as much
of the knowledge of the field as is agreed on, useful in your general
area, and expressible. And you want to err on the conservative side of
expressibility, in order to ensure reasoner support and computability.
So elegance and extensibility really are concerns. (It's not so much
"reuse" you are concerned about as the impact of "repair" to support
additional functionalities. The ripple effect of changes can have
dramatic impact on your formerly "working" applications.) (031)
In the last case, you have no idea what the reasoners will be and what
users will attempt to use your work. So you do something like the
second case. And if possible, you put some kind of label on the thing
that describes your background and which view of certain aspects of the
world this ontology takes. (Because that is the difference between the
potential Web clients and your known clients in the second case.) (032)
Best regards,
-Ed (033)
--
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 (034)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (035)
_________________________________________________________________
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 (036)
|