Re: SUO: Why is IFF and the Lattice of Theories good for SUMO
Adam,
I believe that the joint motion (which I repeat
below) provides exactly what you are asking for:
the opportunity to develop SUMO further under
the auspices of the IEEE SUO project.
It also provides what John D. was asking for:
the opportunity to develop OpenCyc further under
the auspices of the IEEE SUO project. John
acknowledged that point, and he offered to
withdraw his motion for OpenCyc in favor of
the joint motion.
And it recognizes that there is already a project
approved and working under the auspices of the
SUO project that is addressing the problems
of merging and mapping ontologies. Since that
project is already approved, this motion raises
SUMO and OpenCyc to the same status that IFF
already enjoys.
It doesn't block you or anybody else from doing
anything that you want to do. Nor does it force
you or anybody else to do anything you might not
feel is appropriate.
The purpose of the joint motion is to recognize
that we don't have just one content project, but
at least two (SUMO and OpenCyc) and possibly
more that may be added to the mix. Furthermore,
it also recognizes the need for a methodology
for relating these projects to each other and
to other resources, some of which are already
available and others will become available.
> Without even a simple example illustrating in
> detail how IFF might be used on a practical
> problem I don't see how you can advocate it
> as a solution.
Please note that the joint motion does not
"advocate" IFF as a solution. What it advocates
is a bare minimum, which is already supported
by ontology projects, including some of those
that you cited. Furthermore, it advocates that
the IFF people work with both SUMO and OpenCyc
to demonstrate what it can do. What goes into
the final standard will be determined by what
proves to be successful. If IFF doesn't do
anything useful, then it won't go into the
final result.
> For my part though, I don't want to block
> the progress of those who advocate IFF, so the
> best way to do that is to have a separate effort.
> I would hope that you would not stand in the
> way of those who wish to work on SUMO as a proposed
> standard.
Nobody is blocking anybody. On the contrary,
the joint motion simply recognizes that there are
multiple projects, that they are not in competition
with one another, and that they should help each
other whenever possible. It does not force anyone
to work with anybody else, but suggests that they
recognize that they are working toward a common goal.
> People here, like yourself, have a research agenda,
> that is independent from the practical use of a standard.
We all have multiple goals. Among other activities,
I am one of the founders of VivoMind LLC, a company that
is already getting paid to work on some very practical
problems for which we are already using a variety of
ontological resources, including WordNet. And we would
like to make use of a merged version of SUMO, OpenCyc,
and other resources supported by tools along the lines
mentioned in the joint motion (which makes no commitment
to using all or even part of IFF).
> People are already using SUMO, so at least some people
> (including some companies) are already convinced.
That's great. Even more people are using Cyc. That is
why it would be even greater if the two projects would
work together.
John
________________________________________________________
Should the IEEE P1600.1 Standard Upper Ontology
Working Group commence work on a project to develop
a standard based on three starting candidates,
IFF, OpenCyc, and SUMO, and continuing as follows:
(1) The development process shall include a
collaboration of members of all three groups
and other SUO participants to determine how each
of the three starting candidates can complement
and support the contributions of the others.
(2) The results shall include a library of modules
derived from OpenCyc, SUMO, and/or other sources.
Each module shall consist of closely related
axioms and definitions for some aspect of a
standard upper ontology.
(3) The standard shall include the specification
of a methodology for testing the modules for
consistency, relating them to one another in
a generalization/specialization hierarchy,
and combining two or more modules to derive a
new module that is larger and more specialized
than the modules from which it was derived.