Re: SUO: Re: SUO Ballot with 2 Questions
John,
When we both worked for IBM, there was (at least in the west coast labs)
the opinion that for every dollar spent developing new function for a
major software product, ten dollars was spent to integrate that function
into the existing product. This was especially true if the product had
a large and diverse set of installed customers. QA and testing were
major expenses.
I think this circumstance was the source of an old joke: "How was it
possible that God created the world in just six days? He didn't have an
installed base."
Software documentation (such as a registry) is just common sense - and
worth it's weight in gold in many situations. Unfortunately it is
frequently not practiced. After all, how can you be a hot shot
programmer if you waste time (and development dollars) on something as
mundane, uninteresting and unnoticed by management as documentation.
Bob
John F. Sowa wrote:
>
> Folks,
>
> Before getting to some of the remarks on SUO list, I'd like
> to discuss a question that illustrates the use of a registry:
>
> What if Cyc had used a registry over the past 19 years?
>
> The result would have been a valuable compendium of all
> the sources from which the Cyc categories, definitions,
> axioms, and theories were derived. Some would probably
> have been offloaded to dusty tapes that haven't been touched
> in years, others would record the history of versions of
> Cyc as it has progressed, and others would contain very
> frequently used modules and microtheories.
>
> Besides the collection of all those resources, the metadata
> would show who made what updates, changes, and revisions
> when and why. The existence of all that information in
> the repository would be a valuable resource for anyone
> who had a question about any decision that went into
> the design and development of the Cyc ontology.
>
> But most importantly, the existence of old versions in the
> registry does not imply that they have any kind of official
> status. When version 2.6 is released, version 2.5 becomes
> obsolete, but it is important to keep the old versions around:
> for documentation, backup, audit trail, and applications
> that still depend on them.
>
> And when new revisions are made, it is important to go back
> and check the reasons for the old ones. Often there are
> critical dependencies that might be overlooked and the
> new change could cause old applications to fail.
>
> This example addresses a point by Mike Pool:
>
>> Is it that SUO be some conglomeration of largely overlapping
>
> > upper ontologies that may or may not be ultimately adjusted,
> > merged, revised into some standard orntology?
>
> The registry is not the standard. It is a record of the
> development stages. At any point in time, some module or
> collection of modules could be declared as Version 1.0 of
> the SUO reference ontology. But the older stages would still
> exist in the registry for anyone who might still need them.
>
> > Or is it that we accept OpenCyc and SUMO as starter documents,
> > and possibly others along the way. with an understanding
> > that at some later point we will reassess to determine
> > worthiness of the resulting effort as an IEEE standard ontology
> > (perhaps by merging and hopefully by extending and revising
> > but certainly by showing themselves to be sufficiently extensible
> > and modular).
>
> Yes, that is the intent. Just keeping the old versions around does
> not imply that they are "just as good" as the new ones. But they
> represent important steps in the development process, which may
> be important for future developers who need to understand why
> certain choices were made.
>
>> The second half of 5 makes me a little nervous and I worry
>
> > that it complicate things unnecessarily. Why would legacy
> > systems and pragmatic alternatives also be part of a mature
> > IEEE standard?
>
> The legacy systems would not be part of the new standard.
>
> In point #5, I said "the framework should accommodate legacy
> systems and pragmatic alternatives that are not 100% compatible
> with the reference model." What I meant was that the IFF
> methodology (or whatever variation the SUO chooses to adopt)
> should facilitate a peaceful coexistence with older systems
> that have to interoperate with the new standard.
>
> Eric Peterson said that there was one issue left that he
> would like to see addressed by motion #2:
>
> > But do we want to turn into a group that refuses to do something
> > as simple as state as a goal that as a SUO group we are going to
> > merge worthy ontolgies into an upper ontology. We are not the
> > SUOs group (the pluralization of SUO). The direction of this
> > group is obviously getting warped off of its original intent.
>
> Since that goal of producing a unified SUO has been in the charter
> from the beginning, it is still in effect. I wouldn't mind
> adding something along those lines to motion #2, but the voting
> process is already going on. And since I don't believe it is
> necessary to add that clause, I would rather not disrupt the
> current process, wait another 10 days for discussion, etc.
>
> If you feel that the goal requires a repeated affirmation
> or clarification, then you can make a new motion and I would
> be willing to second it.
>
> Pierre Grenon said a lot of things that I agree with to
> a large extent. I would just add a few qualifications:
>
> > To me anything which attempts to make me believe that OpenCyc
> > is better than anything else based on whatever heroic history
> > it has is marketing and bullshit. Cyc has been more shaped by
> > idiomatic intuitions and implementation constraints than
> > anything else. Maybe this didn't prevent it from being
> > successful, not sure it is a good piece of UO.
>
> The only point I disagree with is the implication that Cyc has
> been "successful". For 19 years, it has succeeded in getting
> research contracts. Nobody is buying it and using it to make
> money or to save money on mission-critical applications.
>
> > SUMO is the refined product of a garbage collection and
> > frenetic merging. Maybe the recycling process was efficient,
> > I don't know for sure.
>
> I think that the collecting part of SUMO is more valuable
> than the result of the "frenetic merging". That is why I
> would prefer a larger starting collection and a more
> systematic merging process -- along the lines of IFF.
>
> > I don't like the prospect of refining refined product which
> > have been polutted over the years by the contingency of the
> > moment.
>
> I agree. But I doubt that any new project that started
> from scratch would be any better. It would just make
> different mistakes -- and maybe even worse ones.
>
> > The truth is that legacy ontologies will give you few more than
> > dipshit insight in what you need for a UO and mostly negatively
> > (through their inconsistencies). If you add to that that you will
> > need to add to your registry any this or that ontology in order
> > to imporve the diversity and the breadth of your horizon, you end
> > up with an endless toying in the mud.
>
> I don't really disagree. The only thing that I can say is that I
> am a bit more hopeful than you are (but not much).
>
> I also believe that working on good, small modules is more likely
> to produce something of lasting value than working on trying to
> cover the entire universe all at once. That is why I believe it
> is important to have a methodology such as IFF and a registry
> that can keep track of the modules and their relationships.
>
> John
>
>
>