Response to "Common Semantic Core" Message from Sowa
tony@winston.ontek.com (Tony Sarris)
Reply-To: cg@cs.umn.edu
Date: Tue, 7 Jul 92 10:53:39 PDT
From: tony@winston.ontek.com (Tony Sarris)
Message-id: <9207071753.AA03971@winston.ontekYP>
To: cg@cs.umn.edu, interlingua@isi.edu, kr-advisory@isi.edu, srkb@isi.edu
Subject: Response to "Common Semantic Core" Message from Sowa
Cc: mrg@cs.stanford.edu, sowa@watson.ibm.com
John,
Certainly coordination among the groups working in the area of
integration, particularly knowledge sharing, is a positive thing, but it
sometimes seems that the emphasis gets somewhat misplaced. As the
subject line of your recent e-mail message seemed to indicate at first
glance, the heart of the problem is with the "common semantic core".
Languages for expressing that, while quite important, are truly secondary
to the things being expressed in the language.
As you know (but for everybody else's benefit), the major thrust of
proposed new ANSI standards work in this area is that core set of
semantics (referred to as the Defining and Normative Schema constructs
of an Information Resource Dictionary System or IRDS). Standardization of
CG, KIF, SUMM or whatever as languages for expressing those constructs is
really made necessary by the need to ensure that the constructs are, in
fact, equivalently expressed in those languages. Perhaps it would be more
appropriate to state that the Normative Languages themselves are not so
much "standardized" as "verified" or "certified" --- meaning that some
agreed upon version (a "standard" (?) version) has been reviewed by some
responsible body and found to be capable of expressing the semantics of
the core constructs in the manner in which they are intended to be
expressed (based on some formal definition of them using symbolic logic).
It should be noted though that the "standard" version of these Normative
Languages might not be exactly or entirely the same as versions of the
languages "standardized" by some other body. For example, CG might be
standardized for government use through FIPS, but that standard might not
necessarily match a Normative Language developed based on CG. The same
would hold for a Normative Language based on KIF or SUMM or SQL or
whatever. It might be nice if we could always keep the two in sync, but
the purposes might be quite different (e.g. CG as an interpreted predicate
logic modeling language versus its use as the basis for a Normative
Language for modeling language integration and model content
interchange). Also, the ANSI body responsible for certification of
Normative Languages (SC21 X3H4) might not be the same one responsible
for standardization of the languages in some other "context" such as
software engineering (SC7). Harmonization may help, but what happens if
there is a direct conflict over some aspect of the language in its context
as a modeling language versus a Normative Language? May the best group
win?
In any case, the standard should concentrate on the underlying semantics.
Unfortunately, there has probably been a lot more work performed, and a
lot more agreement reached, in the area of languages than in the area of
underlying primitives for knowledge representation and integration (I
believe Bill Swartout referred to the latter at the January IRDS meeting
as the search for the Holy Grail --- although Holy Cow may be a more
appropriate metaphor).
Regarding set theory. I don't have a problem with basing those primitives
that relate to sets on some generally-accepted definition of set theory
(and KIF may well be the source of such a definition). However, we should
be careful not to impart any special role to set theory as regards
mereology or any other "ology" to which set theory does not apply. In other
words, there can be certain primitives which have as their applicable
contexts representations of things having to do with sets, versus part-
whole, versus whatever. We, of course, will have to specify what you can
and cannot (or at least should and should not) use those primitives for
based on what kind of primitives they are.
Finally, that list of notions or uses of "context" is quite nice ---
particularly for a first shot. Perhaps someone will make use of it as a
guideline for exploring the issues under various R&D efforts.
Regards,
Tony Sarris
tony@ontek.com