Knowledge languages vs. programming email@example.com
Date: Sat, 29 Feb 92 07:19:36 EST
To: INTERLINGUA@ISI.EDU, SRKB@ISI.EDU
Subject: Knowledge languages vs. programming languages
Following is an edited merger of two notes that I sent to CG list. They
were in response to a note about the ICOT Knowledge Language 1, which I
claimed was a programming language, not a knowledge language. That
distinction raises some important issues about the nature of KIF and
related systems. What kind of language should it be?
In 1987, I visited ICOT for a US-Japan AI Symposium sponsored jointly
by ICOT and NSF. Mike Genesereth and I got into an argument with a
couple of the ICOT people about the nature of languages like Prolog.
Both Mike and I were on the same side of the issue -- we claimed
that Prolog was first and foremost a PROGRAMMING language, not a
KNOWLEDGE REPRESENTATION language. That doesn't mean that Prolog
is bad -- in fact, it is a very good language for implementing a
knowledge representation language.
I want to emphasize the point that being a "knowledge" language
is not a mark of excellence -- there are some very good and some
rather poor examples of both kinds of languages. They are just
two different kinds, distinguished by the relationship between
the language and the things that the language refers to. Both are
useful, but for different purposes.
Although Genesereth and I were on the same side in that discussion,
I won't try to characterize his position. I'll just say what I mean
by the distinction between a KNOWLEDGE language and a PROGRAMMING
1. First draw a distinction between the target system T that you
are trying to describe and the language L that you are using to
2. Then look at the variables in the language L and what they are
intended to refer to (in CG terms, what are the referents of the
concepts). If the variables refer to things in T, then it is a
knowledge language. If the variables refer to data structures in
L, then it is a programming language.
3. If somebody claims that L is a knowledge language, check whether
the operations on variables that refer to things in T correspond
to the permissible operations on the actual things in T. For
example, if x refers to a person, then you should not be able to
take a substring of x, add 1 to x, etc. But if y refers to a book,
then you should be able to define operations of "giving" and
"reading" so that you could "give" y to x, and allow x to "read" y.
All natural languages, such as English, French, Japanese, etc., are
knowledge languages. Examples of programming languages include
FORTRAN, COBOL, LISP, PROLOG, and OPS5. Examples of knowledge languages
include conceptual graphs, SNePS, KL-ONE, and some, but not necessarily
all, knowledge representation languages.
What distinguishes a knowledge language is strong typing with a
discipline to ensure that variables and predicates don't get linked
to one another in arbitrary ways. What makes Prolog and OPS5
programming languages is the absence of type checking and the freedom
to violate any established conventions at any time.
Object-oriented languages like Smalltalk, C++, etc., are interesting
examples of hybrids that use the notion of "encapsulation" to separate
the implementation-independent "knowledge" part from the highly
implementation-dependent "programming" part.
Note, by the way, that the target system T could itself be a computer
or a programming language. You could, for example, use conceptual
graphs to talk about FORTRAN. But then the canonical graphs would
have to enforce all the restrictions that FORTRAN obeys: i.e. you
can only add a number to a number, and you can't add a DO-loop to a
This leads to a question about predicate calculus. Is it a programming
language or is it a knowledge language? I would say that the pure,
uninterpreted unsorted predicate calculus is neither -- it is as close
as you can come to a neutral language. It most exactly corresponds to
what Bertrand Russell said about mathematics: "It is a subject in
which you don't know what you are talking about nor whether what you
are saying is true."
Given that pure predicate calculus is neutral, you could add predicates
to it to make it go either way. You could take the Prolog route and
get various kinds of logic-programming languages by adding facilities
for building and manipulating data structures, mechanisms for I/O and
side effects, etc. Then you get a programming language with a logic
flavor. The other route is to develop a strict discipline for defining
predicates that refer things in the real world (or some subset, such as
the target system T). Then the logic plus the disciplines for using it
to refer to things in T becomes a knowledge language. But to keep it a
knowledge language rather than a programming language, you need some
mechanism for enforcing the discipline. That is why I believe that
strong typing is an essential part of a knowledge language.