Dear Ed, (01)
> Matthew West wrote:
>
> > 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.
>
> I agree that I don't understand.
>
> 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. (02)
MW: Clearly. (03)
> It apparently applies to "theory", but it is
> not clear whether it applies to a "design" or a "device". (04)
MW: I think it can be applied to both, but device is at least focussed
on software system, rather than physical devices, though it may apply
there too.
>
> > 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).
>
> I am not sure what kind of analogy is valid here. (05)
MW: Well for now lets just leave it that elegance is a term that
can reasonably be applied to software designs and scientific
theories, and ontologies. Some combination of meeting the
requirements with some sense of minimalism.
>
> 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).
>
> 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. (06)
MW: OK.
>
> 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. (07)
MW: OK.
>
> 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.
>
> 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. (08)
MW: Yes. Thats why I used the word "analogy".
>
> 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. (09)
MW: I agree that it "is not" a theory, but a software system often uses
or supports a theory. (010)
> It follows that the development of software systems is an
> "engineering" task, not a "scientific" task. (011)
MW: Oh. I agree completely. As a Chartered Engineer I could hardly
say otherwise. (012)
> (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.) (013)
MW: Well if we are talking of the knowledge of how in general to
develop software systems, then I agree. But if we are talking about
gaining knowledge of the domain that the system is supposed to support,
then this is part of the (engineering) process. However, it is this
part of the process (requirements and analysis) which is where an
ontology is likely to be created. This I would consider to be developing
knowledge (you often extract things that people didn't know they knew). (014)
> 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. (015)
MW: Which would surprise me greatly.
>
> 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. (016)
MW: Well yes, so?
>
> > MW: I think you are right to link elegance with fruitfulness.
>
> "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. (017)
MW: Exactly.
>
> 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. (018)
MW: I agree, although you might have thought about what sorts of things
it might be used for, and whether those could be accomodated in the
design at little or no cost.
>
> > Specifically, fruitfulness in
> > software design is something that can be deliberately sought,
>
> I agree, (019)
MW: Good. (020)
> but I don't think that explicitly seeking it provides any
> likelihood of having it. (021)
MW: That is a little strong, you are suggesting that fruitfulness is
entirely random. I would agree that elegance is not a guarantee of
fruitfulness, but I certainly think it increases the likelihood of it. (022)
> 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. (023)
MW: Which is different from what you said above. I agree that we are
talking percentages and degrees here. If you will agree that elegant
designs are more likely to be fruitful, I'll settle for that. I quite
accept a design can be elegantly wrong.
>
> In fact, as I said and exemplified, explicitly seeking "extended
> applicability" or "elegance" has often proved to be misguided. (024)
MW: And as I have said before, jsut because something can be done
badly, doesn't mean it can't be done well.
>
> > 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.
>
> I don't understand the reference, but I think I disagree entirely. (025)
MW: What do you disagree with?
>
> 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. (026)
MW: But you are apparantly saying you can't see that on a smaller time
scale within the iterative development of a system. Seems a bit strange
to me.
>
> 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". (027)
MW: Well this is of course what is happening, just on a shorter
timescale.
>
> 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". (028)
MW: You see fruitfulness when you see it, you might see it within the
project development cycle when the project does not over run, because
components did actually work together, rather than conflict, and it
might be when the next tranch of requirements come forward and are
relatively easy to accomodate.
>
> > MW: We really do need the Lewis Carroll principle of meaning here.
>
> Indeed. Thank you, Humpty Dumpty.
>
> 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"? (029)
MW: Not unless we stop talking about what fruitfulness is, and start
talking about how to achieve it.
>
> My excuse for continuing this discussion is that we do need
> some kind of
> guidelines for development of ontologies. (030)
MW: Exactly. (031)
> 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"
>
> In the first case, you know the reasoner, you know the specified
> function set, and reuse and general validitiy are not high
> priorities. (032)
MW: Yes, but it is not harmful, and an elegant design is usually
cheaper to implement at least. Also it is very unusual for systems
not eventually to be linked, in which case an inelegant design will
add significantly to the interfacing costs, e.g. SAP R3. (033)
> (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.) (034)
MW: You seem to be making my case.
>
> 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.) (035)
MW: Yes. I call this stability when extended.
>
> 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.) (036)
MW: Agreed. See my response to Pat for more. (037)
Regards (038)
Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Registered in England and Wales
Registered number: 621148
Registered office: Shell Centre, London SE1 7NA, United Kingdom (039)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (040)
>
> Best regards,
> -Ed
>
>
> --
> 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
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
> _________________________________________________________________
> 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
>
>
> (041)
_________________________________________________________________
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 (042)
|