Re: SUO: Re: SUO Ballot with 2 Questions
John,
I wonder if the issue is a matter of emphasis. The notion of a registry
seems sensible to me. I'd like to think that the way we've used a web
interface to CVS is consistent with this. We've released publicly every
version of SUMO since its inception, and tried to document all the sources
in the CVS comments, or in the SUMO versions themselves. This can be
viewed at <http://ontology.teknowledge.com/cgi-bin/cvsweb.cgi/SUO/Merge.txt>
The focus of the standards effort though seems to me to be not the tools
we use to capture the content, but the content itself. Setting up our
CVS-based registry took an irrelevant amount of time in the context of the
larger project. If someone has a better, free, implemented system, that
would be great.
Adam
At 11:01 PM 6/5/2003 -0400, 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
>