[Top] [All Lists]

Re: [ontolog-forum] Time representation

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Fri, 25 Jan 2008 15:30:39 -0500
Message-id: <479A46EF.4010908@xxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>