Re: An ontology for KIF

macgregor@ISI.EDU
Message-id: <199308181819.AA19385@quark.isi.edu>
Date: Wed, 18 Aug 1993 11:18:36 -0800
To: Tom Gruber <Gruber@HPP.Stanford.EDU>, interlingua@ISI.EDU
From: macgregor@ISI.EDU
Subject: Re: An ontology for KIF


I would just like to reinforce what Tom has just said, with a simple
example of why translation between KR languages requires more than
just KIF plus a theory of (a subset of) mathematics.

Suppose KR languages L1 and L2 are identical, except that L1 includes
as a primitive the concept TYPE, and L2 includes as a primitive the
concept SORT. Let us suppose further that the meaning of TYPE intended
by the designer of L1 is identical to the meaning of SORT intended by
the designer of L2.

Using only KIF, the statement "(TYPE person)" in L1 cannot be
translated into "(SORT person)" in L2. To do so requires an axiom that
says "TYPE in L1 is equivalent to SORT in L2".

What to do? Well, we could create a library of correspondences between
primitive predicates in L1 and primitive predicates in L2. If we create
correspondence entries to enable translation between different pairs of
languages, then we end up with the "n squared" problem that I alluded
to earlier. A better solution is to identify those (hopefully few)
primitives like "type" that are "missing" from KIF, and to put them
into an ontology/theory that can be referenced by a translator.

Note: Tom includes an important proviso for "type" (and for any
other primitive):
> Assuming we could
> give an adequate account of its meaning in prose ...

Its a no-brainer to define a primitive concept "type" and stick it into
an ontology. However, there should also be a semantic account
sufficiently detailed so that implementers of translators will be
comfortable estimating when their own language's notion of type is
equivalent (enough) to the standardized "type" to map into it. Its
possible that a usable ontology/theory would need to have more than one
kind of type (e.g., TYPE1, TYPE2, ...) with different prose
descriptions attached to each of the standard but different notions of
what constitutes a type. Too many kinds of TYPES would doom its utility
-- a net discussion on the meaning of type (shudder!) might reveal
whether common agreement is easy or impossible to achieve.

My conjecture is that the introduction of only a handful of primitives
will suffice for much of what is missing in KIF (whose omission now
prevents KIF from enabling translation between the majority of KR
languages).

Challenge to Jim Fulton: Suppose I have a database schema containing a
relation R1 with columns named A and B, and a relation R2 with columns
named A and C.  How would you model this in KIF (note, its not in
general acceptable to assume that the "A" in R1 has the same definition
as the "A" in R2)?  Again, suppose I have a relation S containing a
column named S. How would you model that in KIF?

- Bob

Robert M. MacGregor                                     macgregor@isi.edu
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292      (310) 822-1511