Re: ANSI standards and knowledge email@example.com
Date: Thu, 25 Aug 1994 12:16:17 -0500
Content-Type: text/plain; charset="iso-8859-1"
To: Erik Sandewall <firstname.lastname@example.org>, email@example.com
Subject: Re: ANSI standards and knowledge representation
At 8:59 AM 8/18/94 +0200, Erik Sandewall wrote:
Im afraid I feel strongly that many of these suggestions are mistaken.
After his intial declaration that standardisation is inappropriate,=
suggests standardising far too wide a range of topics. For example,=
is wholly inappropriate as a standardisation vehicle, as it is only
supported by a subset of operating systems, is archaic in design=
conception, and is extremely idiosyncratic as a handler of text.=
rhetorical device only, let me suggest that Word5 would be far more
suitable. But there is no need to go beyond ASCII in setting a standard.)
I respond below to some of Eriks points
>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=
> researchers", but in this case there are so many glaring open
> questions and remaining possibilities. Some of them are listed=
>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=
> looked at SUMM or CGs so if these things should already be in=
> 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=
> relation symbols also need type declarations, of course.
THe problem here is that there is no uniformly agreed system of typing.
Should types be disjoint, can relation arguemnts be overloaded, etc=
Moreover, any such system can be fairly directly described in untyped=
so the standard need not committ itslef to a nonstandard decision.=
exactly as it should be.
> * 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=
> function and relation symbols as well as types in a module.
This concept of 'module' is a research topic. (See work by McCarthy,=
and others on 'contexts' for example.) It is silly to try to standardise
something which is not even properly understood in the research area.
> * In the context of the sort/type system, there should be a=
> declaring the (finite) domain of a type explicitly. This=
> unique names axioms etc, and is important e.g. for defining
> "discrete value spaces".
Why must sort domains be finite? Eg consider the integers. This already
illustrates the kind of arbitrary decision that one might be forced=
standardising, for no good reason.
> * 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.
Of course they can. The KIF notion =F8f an 'ontology' (read 'axiomatic
theory') allows exactly such an addition. Of course, the details=
topics of time, action, etc,. are even less universally agreed than=
> * 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.
Here I agree. Let me put in a slight boast to the effect that KIF=
only standard proposal I know of that has a semantics. The semantics=
CG's is not precisely defined and seems to be intertwined with many
idiosyncratic and highly 'nonstandard' philosophical positions.
>Additionally, I propose that the typographical basis should be
>LaTeX and not ASCII. In other words, rather than defining expressions=
>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.
See above. While I sympathise with the spirit of this, the choice=
is a terrible idea. And why not keep the syntax as simple as possible?
ANyone who wishes to write a specialised parser is free to do so=
the expressions in what they consider to be a more readable form,=
eg as a
CG graph, or using infix notation, etc etc.
Beckman Institute (217)244 1616=
405 North Mathews Avenue (415)855 9043 or (217)328 3947=
Urbana, Il. 61801 (217)244 8371=
Phayes@cs.uiuc.edu or firstname.lastname@example.org