Re: Some Thoughts on K.I.F.
Jeff Van Baalen <vanbaale@tc.pw.com>
Date: Thu, 9 May 91 15:19 PDT
From: Jeff Van Baalen <vanbaale@tc.pw.com>
Subject: Re: Some Thoughts on K.I.F.
To: labrea!interlingua@isi.edu
Message-id: <19910509221911.6.VANBAALEN@lira.tc.pw.com>
While I agree in spirit with the points that John Sowa makes in his
message and applaud his attempting to be concrete, I find some of the
particular examples given to be unconvincing.
The first example focuses on whether or not "flies" should be recognised
as a type (sort,...) when translating
(Ax)(bird(x) -> flies(x))
>From KIF into a target knowledge representation system. It seems to me
the answer depends on whether or not there is more information about
"flies" in the KIF version of the KB than the above statement. If not,
then "flies" can be treated as a type. If so, perhaps the additional
information distinguishes "flies" as a non-type predicate.
The second example focuses on recovering cliches like "exactly-one" from
first-order statements. This, I think, is a more substantive example.
However, I have worked for some years on a system called DRAT. Part of
what DRAT does is recover exactly this kind of information from "raw"
first-order PC. It does this by rewriting statements in raw PC into
statements involving set terms and then recognizing cliches of this kind
in the set notation. As a simple example, consider the statement
(married(x,y) & married(x,z)) => y=z.
DRAT rewrites this as
married(x,y) => subset({z|married(x,z)},{y}),
This statement is recognized as an "atmost" constraint.
It turns out that this system of rewrites is capable of placing in a
recognizable form all of the various ways I (and several of my colleges)
have thought of to express these kinds of constraints.
Again this message is not meant as disagreement with Sowa's general
message, just that, while there are real problems of the sort he
mentions (such as "most" which he does mention), things may not be as
bad as he thinks.
Jeff
----