Re: SUO: OpenCyc Motion

[Pierluigi Miraglia <miraglia@cyc.com>]

On Sat, Jun 01, 2002 at 11:36:18PM -0400, John F. Sowa wrote:
> MP> Secondly, is it part of this group's purpose to make a decision
>  > as to whether CycL or any language is to be the/a knowledge
>  > representation language for IEEE standard ontology?    Even if
>  > does make sense for us to focus our energy on the selection and
>  > development of a KRL, it seems that the decision of whether or not
>  > to consider/develop OpenCyc is based on very different sorts of
>  > considerations than a question of whether or not to consider/develop
>  > CycL as a standard KRL.   Hence, I'm not sure it makes sense to
>  > conflate the two decisions in a single motion.
> 
> I agree with this point more strongly than I agree with the
> previous one.  At various times in the past dozen or so years,
> I have talked with Doug Lenat, Fritz Lehmann, and other Cyclers
> about the differences between CycL, KIF, conceptual graphs, and
> other similar languages.  At other times, various people, including
> many of my friends and colleagues, have written translators to and
> from CycL and KIF, CGs, and other logic-based languages.  These
> translators have always managed to capture a sufficiently large
> subset of both CycL and the other language to support useful
> interoperability.

I should premise that while I share Mike's expressed misgivings about
CycML, I'm of the opinion that CycL is suitable to be a
general-purpose kr and knowledge entry language. But I would be
interested in knowing your (John Sowa's) comparative results about CycL,
CG and KIF, and others if available (I imagine your book to be a source
w.r.t. CG, but please send pointers to others).

> 
> For these and many related reasons, I believe that the language
> used to express the OpenCyc ontology should be standardized as part
> of the proposed ISO standard for Common Logic (CL).  That standard
> has developed a common semantic foundation for KIF, CGs, and an
> infix notation that uses the traditional symbols of predicate
> calculus.  There is a very large subset of CycL that could be
> supported directly by the CL standard.  There are some esoteric
> parts of CycL that various people on the CL committee have studied,
> but none of us are willing, by ourselves, to commit to supporting
> within the CL framework without some convincing by people who know
> and understand CycL and the reasons for those features.

> Recommendation:  I propose that the subset of CycL required to
> express the OpenCyc ontology be standardized by the same ISO process
> that is developing the CL standard.  That would be the fastest way
> to develop a standard for CycL (or some subset thereof), and it would
> ensure complete interoperability between that version of CycL and
> every other notation included in the CL standard:  KIF, CGs, and
> infix predicate calculus.

I am all in favor of taking this into consideration and doing the work
you propose (it's work that I generally enjoy doing :), but I also
believe that it should not be impossible to at least consider as
potential standards languages that have additional expressive or
inferential power.  So, imho, you are perfectly free to propose that a
standard KRL should be one that doesn't exceed the "minimal KRL standard"
as specified by CL, but this proposal in itself would seem to me a matter
of some debate, and as such should be not be considered at this stage as
grounds for rejecting any candidate potentially exceeding this avowed
"standard." 

I am not saying that I necessarily *will* disagree with you after I have
done my homework, all I am saying is that your criterion, as currently
formulated, should be a matter of consideration in the discussion, not
part of a motion we can formulate at this stage. 

> 
> MP> Pierluigi, I'm wondering if you would consider retracting this
>  > motion and resubmitting it as three separate motions.
> 
> Yes, and I would like those three motions to include something along
> the following lines:
> 
>   1. A subset of CycL, called CommonCycL, shall be defined with the
>      same semantics as the proposed ISO standard for CommonLogic (CL).
>      The specification for CommonCycL shall determine a formal mapping
>      of every statement in CommonCycL to and from the abstract syntax
>      of the proposed CL standard.  That mapping shall be sufficient to
>      allow any ontology specified in CommonCycL to be translated to
>      any other language specified in the CL standard, and it shall
>      also be sufficient to allow any ontology specified in any of the
>      other languages of the CL standard to be translated to OpenCycL.
>      Any ontology translated by these mappings shall have the semantics
>      defined for the abstract syntax of CL.  (Note:  I coined the term
>      "CommonCycL" for this note, and I would leave it to Pierluigi or
>      others to decide on whatever name they would prefer.)

Precisely: as I said, this is something I would _not_ want to include in
the current motion about cycl (whether separate from or of a piece with
the opencyc motion). Upon learning more about what CommonCycL would be, I
(and everyone else, I imagine) personally may or may not agree with you
on 1.

> 
>   2. The content of the OpenCyc ontology shall be specified in
>      CommonCycL or any other language of the proposed CL standard.
>      The semantics of any statement S of the content shall be determined
>      by the semantics of the statement obtained by translating S to
>      the abstract syntax of CL.

Same as above. 


>   3. I won't say anything further about CycML until I hear more about
>      it, including some reasons why it should be standardized at all.
> 
> I would also like to hear more about how the OpenCyc developers plan
> to interact with the developers of the other two candidates, SUMO and
> IFF.  As I have said in many notes, I have not been at all happy with
> the complete separation of efforts of SUMO and IFF.  If the OpenCyc
> developers would be willing to work with the SUMO and IFF developers
> toward a convergence of all three, I would enthusiastically vote to
> support OpenCyc as a candidate on an equal footing with SUMO and IFF.
> But if OpenCyc is viewed as a separate, independent, or perhaps even
> a competing effort, then I would either abstain or vote against it.

John DeOliveira would have a more informed opinion about this. 

Regards,

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