Re: ANSI standards and knowledge representationgenesereth@cs.Stanford.EDU (Michael R. Genesereth)
Date: Thu, 18 Aug 1994 12:14:46 -0700
To: Erik Sandewall <firstname.lastname@example.org>
From: genesereth@cs.Stanford.EDU (Michael R. Genesereth)
Subject: Re: ANSI standards and knowledge representation
Cc: email@example.com, genesereth@cs.Stanford.EDU, firstname.lastname@example.org, email@example.com,
A somewhat lengthy reply to your note. Sorry.
The first thing to realize is that thare are THREE relevant projects under
discussion within x3t2, not one, as suggested by Matt's note.
(a) There is the effort to produce a standard for conceptual schema
modelling facilities (which is what the X3T2 committee seems to care about
most at the moment). This project requires that we harmonize different
approaches to semantics, e.g. the CG aproach, the SUMM approach, the KIF
(b) There is a project to standardize CGs in particular.
(c) And there is a project to standardize KIF in particular.
I am not sure which of these projects your note refers to. For the first
project, it makes sense to ask whether the semantics of KIF or CGs or SUMM
or basic fopc etc should be used. For the second project, it makes no
sense to suggest that CGs are not appropriate. That is the DEFINITION of
the project. Ditto for the third. It makes no sense to ask whether KIF is
appropriate. It is the definition of the project. It would make as much
sense to say that people in x3J13 (the Common lisp committee) should have
considered C. These latter projects are concerned with specific languages,
NOT enshrining one language for all.
In this regard, by the way, note that there is no restriction to working on
just these two langauges, though only these two projects exist at the
moment. Other languages may someday be standardized as well, just as we
have standards for multiple programming languages.
In the following, I have tried to respond to soe of the specific points you
raised in your note. Again, I am not sure whether you are talking about
the csmf project or the cg project or the kif project. My comments relate
to the kif effort.
>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.
(1) With regard to KIF, I agree that we do not as yet have a proposed
standard that everyone will agree to. However, I think we are quite far
along, and ANSI and ISO give us a neutral forum with appropriate procedures
for hammering out the remaining details. Remember that we are at this
point asked only to produce a dpANS (i.e. draft proposal for an American
National Standard). Once produced, it will be subject to critique and
revision before final approval, probably several years off.
> * 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.
(2) This issue has been raised and discussed extensively by the KIF
committee and beyond. While recognizing the importance of typing, the
committee has so far, for a variety of reasons, not recommended that we go
to a fully typed language. The current resolution on this subject is to
have type-like quantifiers in the language without additional semantics.
The most interesting proposal on the table in this regard is that of John
Sowa and Pat Hayes, who suggest a syntax like the one you suggest,
(forall ((?x integer)) (> (+ ?x 1) ?x))
without an extension of te semantics, i.e. the preceding sentence would be
(forall (?x) (=> (integer ?x) (> (+ ?x 1) ?x)))
(3) In another point you talk about modules and the like. To date, there
has been a lot of discussion about McCarthy's contexts as a possible
approach, but that work is too speculative at this point to bring into the
language a this point. Some members of the committee feel that such issues
should be relegated to a wrapper language, like KQML.
> * 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.
(4) You say that KIF should include coverage for time, actions, events,
procedures and so forth. This is a sensible proposal, but many feel that
these issues should instead be the subject of ontologies. When we proposed
putting them into KIF (at the Pajaro Dunes meeting), the proposal was met
with widespread dismay, from the point of view that (a) KIF should be
small, leaving such content issues to ontologies, and (b) we are not ready
to select any one particular treatment (although we COULD standardize
various competing ontologies).
> * 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.
(5) The proposed standard specifies both syntax and semantics. Syntax
alone is not much use. In fact, x3T2's initial interest in KIF is derived
mostly from its semantics. Propositions and possible worlds can be
accommodated within KIF, as first order entities, but they are not
predefined in the core language. Again ontologies.
(6) On the scope of KIF. There are those who argue that even fopc is too
much. There are those who want more than is in KIF. I deal with both
constituencies on a weekly basis. What we have done here is to make a
judicious choice of essential constructs that should be sufficient for
those who want to communicate using simple fopc and at the same time
support those who want more (via the metalinguistic features of the
Note that the KIF effort makes no pretense to give final answers to every
question concerning knowledge representation; but it addresses enough of
the central issues to allow people to start writing programs capable of
exchanging knowledge. There is growing demand for this technology, and the
many users of KIF and its kin have expressed comfort that, with the ANSI
effort, there may be some stability, at least on the core of the language.
Researchers may continue to wrangle about issues but some folks want to get
moving on implementations and think there is enough here to proceed. How
about joining the effort to iron out the remaining issues. That is one way
to be sure that your concerns are met. We could use your help.