Common semantic core
sowa@watson.ibm.com
Message-id: <9207062349.AA21491@cs.umn.edu>
Reply-To: cg@cs.umn.edu
Date: Mon, 6 Jul 92 19:49:23 EDT
From: sowa@watson.ibm.com
To: INTERLINGUA@ISI.EDU, KR-ADVISORY@ISI.EDU, SRKB@ISI.EDU, CG@cs.umn.edu
Cc: MRG@CS.STANFORD.EDU, FIKES@SUMEX-AIM.STANFORD.EDU
Subject: Common semantic core
On June 23, I was visiting the Bay Area and had a two-hour discussion
with Mike Genesereth about the current status of KIF and some of the
issues that we have been discussing via email. Philosophically, we had
broad areas of agreement, and we recognized that there is a high degree
of overlap in semantic features underlying KIF, KRSS, conceptual graphs,
and other logic-based languages such as SNePS and the PDES Semantic
Unification Meta-Language (SUMM). We also agreed that many of the
features that people would like to include in the semantic core have
complex interactions with one another. Instead of just adding features
>From a checklist by majority vote, we should first analyze all the
interactions to make sure that there are no lurking contradictions or
paradoxes.
Last week, I prepared a summary of the points we discussed and sent
a copy to Mike Genesereth and Richard Fikes. Today, I talked with
Mike on the phone to make sure that I wasn't misrepresenting his
position. Following is a revised version based on our phone
conversation.
John Sowa
_________________________________________________________________________
1. Types. At the KR Advisory Board meeting on March 28, I discussed
this point with both Mike and Richard. Mike agreed that it would
not cause major theoretical problems to add types or sorts to KIF
and that they would be useful in simplifying the mapping to typed
languages such as KRSS, conceptual graphs, and most versions of
semantic nets and object-oriented languages. But Mike and Richard
have not yet made a final decision on adding types to KIF, since
there are still some issues that remain to be resolved, especially
in the interaction of types with sets and some of the other details
of the language. I agree that the interaction of types and sets is
a critical issue, and it should have high priority.
2. Set theory and mereology. Mike and I agreed that mereology has some
interesting properties that make it useful for certain kinds of
knowledge representation, but that set theory is so widely used that
it must be included in the semantic core. We agreed on the following
direction:
a) Set theory as defined in KIF should be adopted as the basis for
defining structures. The distinctions between different axiom
systems (such as Zermelo-Fraenkel or Von Neumann-Bernays-Goedel)
are only relevant to applications that talk about nondenumerable
sets, which could never be implemented in any computer system.
I have philosophical doubts about the usefulness (or even the
existence) of such sets; but if anybody wants to talk about such
things, the language should permit them to do so.
b) The axioms for mereology could be stated in KIF or CGs as needed,
and the part_of relation for mereology could be identified with
the subset relation for sets. However, part_of could also be
applied to things that are not sets, such as fluids or other
continuous things that have no clearly marked joints or seams.
3. Contexts. Mike and I agreed that there are many distinct uses that
people have suggested for contexts, and many of them lead into
thorny research issues that have not yet been resolved to everyone's
satisfaction. Following is a list (by no means complete):
a) Partitioning a knowledge base into more manageable modules.
b) Encapsulating parts of a knowledge base, as in the so-called
object-oriented systems.
c) Providing a shorthand notation for omitting common arguments,
such as location, time, etc.
d) Providing a way of resolving indexical referents, such as
"this", "that", "I", "you", or definite noun phrases beginning
with "the".
e) Representing environments whose modality, level of certainty, or
hypothetical existence is different from that of the containing
environment.
f) Supporting propositional attitude verbs (such as believe, know,
think, want, hope, fear, expect, etc.).
g) Separating a metalevel of language that is used to talk about
the language that is used inside the nested context.
We agreed that all of these uses are important, but that a lot of
study is needed to sort them out. Some of them are more clearly
necessary than others, and the initial semantic core might not
support all of them. The question of which ones should be in the
core is an issue for further discussion.
4. Multiple representations. We agreed that a linear language such
as KIF has an advantage as an interchange format that is used for
transmissions along a wire. We also agreed that a graphic language
such as conceptual graphs is more readable for ordinary human beings.
KIF and CGs have a large overlap in their semantic bases, and the
semantic differences between them are negotiable. Therefore, we
should work towards developing a common semantics that can be
expressed equally well in both forms and with a formally defined
mapping between them. But this common mapping between KIF and CGs
should not preclude anyone else who has an equally expressive
language, in either linear or graphic form, from developing it as
another possible representation for the common semantic core.
5. Standards efforts. Conceptual graphs are already being considered
as a possible language for standardization by the ANSI and ISO
IRDS groups. We should develop a joint proposal to ANSI and ISO
with KIF as an interchange language between computer systems,
CGs as a presentation language for a more readable human interface,
and a common semantic core for both.
The standards processes usually take years. Therefore, no one should
consider the current versions of either KIF of CGs as immutable. Mike
and I plan to present a joint proposal to the appropriate groups in
late 1992. A draft standard might appear sometime in 1993, but an
official ANSI and ISO standard is not likely before 1995. However,
we hope that the draft standard of 1993 would be fairly close to the
official standard of 1995 or 1996. Much of the time between 1993 and
1995 would have to be devoted to explaining the standard, working with
people who are developing prototypes, and negotiating change proposals
>From all the groups that expect to use it in one form or another.
Standards evolve, and anything that is missing from an early draft
or standard could still be added to standards that might be developed
in 1999 or beyond. Remember that FORTRAN was first implemented in
1957, but people are still developing new standards for new versions.
So any omissions from the early versions could be accommodated later.