Copy of note to Elizabeth Fong
sowa <sowa@turing.pacss.binghamton.edu>
Date: Sat, 27 Mar 1993 19:25:39 -0800
Message-id: <9303280250.AA03991@turing.pacss.binghamton.edu>
Comment: List name: SRKB-LIST (do not use email address as name)
Originator: srkb-list@isi.edu
Errors-To: neches@ISI.EDU
Reply-To: <sowa@turing.pacss.binghamton.edu>
Sender: srkb-list@ISI.EDU
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: sowa <sowa@turing.pacss.binghamton.edu>
To: Multiple recipients of list <srkb-list@ISI.EDU>
Subject: Copy of note to Elizabeth Fong
>From sowa Sat Mar 27 11:38:45 1993
Received: by turing.pacss.binghamton.edu (4.1)
id AA03656; Sat, 27 Mar 93 11:38:39 EST
Date: Sat, 27 Mar 93 11:38:39 EST
From: sowa <sowa>
To: fong@ecf.ncsl.nist.gov
Subject: Comments on questions about logic and OO models
Cc: sowa
Liz,
Following are some comments on questions that arose at the joint
meeting of X3H7 and X3H4. Could you please forward this note to your
mailing list of X3H7 members.
Thanks, John
_____________________________________________________________________
> Why choose one logic system over another?
All systems of first-order logic are exactly equivalent to one
another. Therefore, the choice of one or another is purely a matter
of personal preference, convenience, availability of tools, etc.
However, it is necessary to choose at least one concrete notation
in order to have some way of recording and communicating whatever
models have been represented.
In order to avoid the so-called "religious wars" between competing
systems, we had a meeting of the KIF, CG, and SUMM developers to
agree upon a common position: to adopt both the KIF and CG syntaxes,
to adopt ontological primitives from SUMM for defining other languages,
and to adopt the model theoretic basis of KIF n for a
common semantics. Therefore, anything represented in either KIF or
CGs could be automatically translated to the other, and either one
could use SUMM ontological primitives (or others that may be developed)
for representing object models or anything else.
> Why is CG a superior interface?
Conceptual graphs have a graphic interface that many people find
very readable. But because of the agreement on KIF, CG, and SUMM,
CGs and KIF can be automatically translated to one another, and
anyone is free to mix or match CGs and KIF in any combination they
find convenient. Furthermore, anyone who prefers to develop a new
syntax or adapt an older syntax, such as Z, is welcome to do so,
provided that they represent exactly the same semantics.
Therefore, we should ask "Why is the common semantic base of KIF
and CGs superior?" That is a very complex question that cannot be
answered briefly here, but both Mike Genesereth and I plan to attend
the joint X3H4.6 and X3H7 meeting on July 20th, and perhaps we can
both clarify the various issues. If I had to give one very short
answer, however, I would say that the metalanguage capabilities of
KIF and CGs are what makes them very powerful as definitional
languages -- that is essential for defining object models, conceptual
schemas, and various kinds of logics and programming languages.
> Is CG a tool for specifying object models or is it in competition
> to the OO concept?
In my talk in San Antonio, I showed a simple object model and its
representation in conceptual graphs. However, I was not trying to
propose any particular object model, but to show how logic, in the
form of either KIF or CGs, could be used to define object models.
Therefore, I would say that the CG-KIF coalition is a basis for
specifying object models, and it is not in competition with any
of them.
There were also some interoperability questions that I would like
to comment on:
> A subsumption model such as CG is capable of being mapped to
> all models. This approach may not solve the interoperability problems.
A formal definition in terms of CGs, KIF, or any other notation
will not, by itself, solve the interoperability problems. But it
is a necessary first step towards relating and classifying different
models. The matrix of features is useful for an overview of many
different models, but it is too simplified to show how the features
interact. Two different models may have features with similar names
and functions, but the details may make them completely incompatible.
Therefore, a formal definition of the various models in logic is a
necessary follow-on to the matrix classification and a prerequisite
for defining precise groundrules for interoperability.
> Frank Manola and Sandra Heiler of GTE submitted an article on
> "Reduced Instruction Set" or "RISC" object model as an approach
> to interoperable object models.
I would say that this seems to be a step in the right direction,
but such a RISC object model must be specified precisely in some
language, and a version of logic would be the best candidate for
a specification language.
> The translator approach, e.g., Express to C++ translator, is an
> example of interoperability between Express and C++.
Translators are useful when you only have two languages that need
to cooperate. But if you have N languages, you need N*(N-1) pairs
of translators. That is why X3H4 proposed the subsumption approach
as a framework for a large family of interoperating systems.
I would also like to make a comment about C++: More than any
other OO language, it is close to being a "RISC" OO language.
That means that its own object model is so primitive that it is
necessary for anyone who uses C++ to augment it with a library
of definitions that make it usable for a particular family of
applications. The real object model is therefore C++ as augmented
with a particular library.
Therefore, the Express to C++ translator is not an example of
interoperability between Express and "bare" C++, but an example
of interoperability between Express and C++ augmented with a
library of definitions to support the Express object model.
If someone else is using C++ with a different library of
extensions, they would still be incompatible with the Express
object model even though they were using the same underlying language.
The point of this comment is that even if you built N*(N-1) pairs
of translators, programs translated to language X from incompatible
sources A and B would be just as incompatible on the X platform as
they were on their original platforms.
Bottom line: I don't believe that there is any magic answer to
interoperability. But I do believe that formal definitions in logic
of the various object models together with a subsumption model of
the various models would be an important step towards groundrules
and conventions for interoperability.
John Sowa