ANSI standards and knowledge representationErik Sandewall <email@example.com>
From: Erik Sandewall <firstname.lastname@example.org>
Date: Thu, 18 Aug 94 08:59:59 +0200
In-reply-to: Matthew L. Ginsberg's message of Wed, 17 Aug 94 09:49:56 PDT <9408171649.AA06846@t.uoregon.edu>
Subject: ANSI standards and knowledge representation
Answers to your questions 3 and 4:
3. No, I do not think the time is ripe for standardization. I realize
that the standardization community feels "time is never ripe for the
researchers", but in this case there are so many glaring open
questions and remaining possibilities. Some of them are listed below.
4. KIF or pure FOL? Neither. I agree FOL can be a point of departure,
but the following modifications seem to be essential. (I have not
looked at SUMM or CGs so if these things should already be in the
US proposal then these objections fall, of course).
* Every usage of FOL for KR purposes seems to require a multi-sorted
logic. This facility should be in there from the start, either
in the quantifiers (\forall v \in Vehicles [...]) or by
separate declarations of the type for each variable. Function and
relation symbols also need type declarations, of course.
* A "module" concept a la programming languages is important.
Set theory, for example, is of course needed in many applications,
but may be defined as a module. It should be possible to "hide"
function and relation symbols as well as types in a module.
* In the context of the sort/type system, there should be a way of
declaring the (finite) domain of a type explicitly. This involves
unique names axioms etc, and is important e.g. for defining
"discrete value spaces".
* Time, actions and events, and change arise in a very large
number of applications, and represent a large part of the
difficulties. I think they should be in the basic formalism,
because they can not conveniently be added afterwards.
* If the proposed standard only specifies syntax and not semantics,
then I do not see the reason for not allowing modal operators.
* On the other hand, I think a serious proposal should define
the semantics as well.
Additionally, I propose that the typographical basis should be
LaTeX and not ASCII. In other words, rather than defining expressions in
the language as sequences of ASCII characters that can be read by
COMMONLISP, they should be LaTeX expressions which can both be presented
in normal "textbook" style, and can be read by specialized parsers.
That overhead is certainly acceptable.