Re: SUO: Re: SUO Ballot with 2 Questions
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