SUO: Further clarifications on the OpenCyc ballot

[Pierluigi Miraglia <miraglia@cyc.com>]

Jim et al.,

although it appears that the retract and resubmit option is not available
at this point, as the proposer of the OpenCyc motion and after hearing
out several other people (including opencyc project manager John
DeOliveira) I'd like to make a belated attempt at clarifying the
"intended interpretation" of the OpenCyc motion:


1. We are not proposing a single standard package consisting of OpenCyc,
CycL, and CycML. Each of these 3 is proposed as a subject of further work
by this group. By this we mean that, at some level, we'd be happy if any
or all of these 3 were developed into one or more IEEE standards.

Our understanding was that a 'yes' vote to the motion would mean that the
SUO WG would next determine such things as: is either/all/none of the 3
"objects" a suitable subject for this WG? If so, how many standards? How
many starter documents? Related by what degree of interdependence? How
bounded, precisely? Etc.

Among the things that a 'yes' vote does _not_ mean: that CycML will be
developed as a standard; that CycML will be approved as a standard if
the OpenCyc ontology is; that either CycML or CycL will be developed as a
standard; etc. 

Thus, in intent at least a 'yes' vote does _not_ entail a rejection of
such positions as represented by, among others, Mike Pool (cycml doesn't
belong), John Sowa (cycml doesn't belong, and only commoncycl is a
suitable standard) and Adam Pease (neither belongs). In fact, I think the
interpretation I am suggesting is perfectly consistent with the wording
of the current ballot. But in order to avoid a protracted dispute on the
interpretation of my own words, I am fully prepared to retract and
resubmit the ballot with more explicit wording, if the rules allow (it
appears that they don't).

If they don't, and if the ballot is approved as is, I hope there will be
motions to split up what needs splitting and to begin discussion on the
merit of Mike's, John's and Adam's points.


2. There was, on the other hand, considerable ambiguity on the
specification of _what material_ was being proposed. (Thanks to Frank
Farance  for pointing this out, and then explaining to us how the mess
could be cleared up.) The ballot referred to URLs, giving the impression
that the content of the proposal was to be identified with the content of
the pages referred to.

So let me have another go at it:

   2.a: The Ontology.
   we propose the ontology contained in OpenCyc 0.x (currently only 0.6b is
   available). This covers the concepts and assertions that can be currently
   inspected via the knowledge browser that ships with OpenCyc. We will most
   likely propose to exclude a set of "implementation constants" that have no
   general-purpose ontological value but are included to allow the Cyc KB to
   maintain a representation of various aspects of our (Cycorp's)
   implementation. These constants will be clearly marked out -- as
   instances of, surprise, #$ImplementationConstant -- in the coming 0.7
   release.
   
   At the moment, however, we don't have a single document or set of
   documents containing all and only the Opencyc ontology as described
   above. We imagine that such a document will be produced, and tools for
   transferring content to flat files are being prepared. Nevertheless, I
   hope that the above description, though still fuzzy at the edges, should
   give SUO members a sufficiently well defined focus for their
   consideration.
   
   Note that the proposal to split off implementation constants is not
   itself part of this motion: the WG may decide to include them after all
   (though I would find that odd), but in any case this is a subject for the
   next phase of the discussion.
   
   2.b: the DAML files mentioned in the original ballot.
   This is a proper subset of the opencyc ontology, therefore not the
   complete extent of what we are initially submitting to the SUO WG for
   further work. Take it as additional documentation, not as specifying the
   boundaries of the content proposed.
   
   2.c: the "vocabulary pages" also mentioned in the original ballot.
   These, too, are only a partial view of the upper ontology. They don't
   include all constants, nor do they list all relevant assertions about
   them. Again, take these as a (partial) illustration or user documentation
   of what we are submitting.
   
   2.d: the "syntax of cycl" and "cycml specification" URLs.
   These documents are sufficiently descriptive of the respective languages.
   I can't really say anything illuminating about CycML, but I expect CycL
   will need a considerably more rigorous specification to pass muster as a
   general-purpose KRL with the SUO WG, so this document is at best a first
   step.


3. Copyright and "strategic" issues.

The OpenCyc ontology is released under the LGPL.  (The version of the Cyc
knowledge browser and inference engine that ships with opencyc is not
under LGPL, but I presume this is irrelevant to the working of this
group.) So anybody can modify the ontology at will and re-release under
the same license (actually the license even allows developers to link the
LGPL-covered material into applications not released under (L)GPL, but I
suppose that's also irrelevant in the present context). 

A fortiori, the SUO WG can modify opencyc as desired for the purpose of
formulating an upper ontology standard. A fortiori, the SUO WG may decide
to merge the OpenCyc with SUMO, IFF or others, if that is what seems
promising as a candidate standard.

I hope this helps some SUOers (suitors?). I trust that if I am guilty of
misunderstanding or misconstruing the going rules and regulations I'll be
reined in promptly.

Regards,

-- 
- - - - * * * * * - - - - * * * * * - - - - * * * * * - - - -
Pierluigi Miraglia                  Cycorp, Inc.
Ontological Engineer                3721 Executive Center Dr.
(512) 514-2988                      Austin, TX 78731