Re: KIF and packages

macgregor@ISI.EDU
Message-id: <199306282035.AA14017@quark.isi.edu>
Date: Mon, 28 Jun 1993 13:34:18 -0800
To: ontolingua@HPP.Stanford.EDU
From: macgregor@ISI.EDU
Subject: Re: KIF and packages


> So consider this simple proposal: KIF is read and printed in packages that
> are disjoint from the built-in Common Lisp package, and package prefixes
> are to be avoided in KIF expressions.

I endorse the second half of this.  Our experience in building a Loom
server found that package prefixes are a real pain (why am I not
surprised).
Also, packages have no analogue in other languages.  So, its preferable
that an ontology (or collection of them) use a single package.  On
the other hand, many Loom applications use multiple packages.  How
would this proposal translate them into KIF?

Regarding making KIF:LISP distinct from COMMON-LISP:LISP, etc:
Loom makes the opposite choice.  We can do so because we are 
careful not to hang information on these symbols.  One price
we pay is that we have to generate additional symbols (one per
concept or relation) that are hidden from the user.  Hanging
information directly off of the user symbols is a big mistake, independent
of the problem of colliding with the COMMON-LISP package.  Suppose
I have two KBs that each define their own concept FOO (i.e., I have
to distinct FOOs).  It should be possible to load and access both
KBs (and both FOOs) from a single application (and in Loom it is
possible).  My impression is that KIF currently maintains a single
global namespace, and couldn't support this.  I regard this as
a defect in KIF.  If KIF were fixed, then the first problem
(collision with the CL package) might have an alternative solution.
Perhaps adding contexts to KIF will provide a solution.

Suppose we adopt the above proposal.  Loom applications assume
that LISP:LIST and LOOM::LIST are eq, that LISP:SET and LOOM::SET
are eq, etc.  Its not clear to me whether or not this causes a problem.

In summary, my chief criticism is that KIF doesn't yet provide
any means for partitioning up the name space.  I think that
it should, and I think that any decision made in advance of such
a partitioning mechanism should be considered provisional until
such time as a partitioning mechanism is adopted.  Once we have
partitions, packages become a redundant means for partitioning
the names space, and for that reason alone should be eliminated.

- Bob

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