Re: KIF counterproposal

Matthew L. Ginsberg <>
Date: Fri, 21 Sep 90 11:17:12 -0700
From: Matthew L. Ginsberg <>
Message-id: <9009211817.AA03046@Sunburn.Stanford.EDU>
Subject: Re: KIF counterproposal
Let's see.  Danny Bobrow sent me a message that although different in
spirit was similar in effect, asking me how I would translate a particular
frame definition into my proposed KIF.  Here's my response:


Danny's frame-language information:

(defconcept  foo (isa bar)
    (a :defaultvalue 1)
    (b :defaultvalue 2))

Here is my proposed translation.  It is longer than his but nothing is
lost and it's all pretty obvious.

:frame-header (type value subtype unique default)
:label l1

;; description of subtypes

(forall ?super ?sub ?obj
  (if (and (subtype ?sub ?super)
	   (type ?obj ?sub))
      (type ?obj super)))

;; what it means for a slot to have a unique value (note
;; that existence is also assumed)

(forall ?type ?prop ?v1 ?v2 ?obj
  (if (and (unique ?type ?prop)
	   (type ?obj ?type)
	   (value ?obj ?prop ?v1)
	   (value ?obj ?prop ?v2))
      (= ?v1 ?v2)))

(forall ?type ?prop ?obj
  (if (and (unique ?type ?prop)
	   (type ?obj ?type))
      (exists ?val (value ?obj ?prop ?val))))

;; what it means for a slot to have a default value

:default NIL
:label l2

(forall ?type ?prop ?val ?obj
  (if (and (default ?type ?prop ?val) (type ?obj ?type))
      (value ?obj ?prop ?val)))

:cancel l2
:cancel l1

;; the definition of foo.  Others would be similar

:frame-definition foo
:label l3

(subtype foo bar)

(unique foo a)
(unique foo b)

(default foo a 1)
(default foo b 2)

:cancel l3


Let me explain how I believe this addresses your concerns.  First,
note that the l3 label wraps around the entire definition of the
concept "foo" at the end of the document.  This is exactly the sort of
pointer you asked for -- telling a frame-like system that a single
concept (foo -- note the argument to the :frame-definition keyword) is
being defined.

Note also that the header to the file, which is a first-order
description of what the various frame constructions mean, is also
separated from the rest of the document with the label l1.  This is
telling any frame-based system that the material within the scope of
the label is nothing more than a header that axiomatizes frames -- and
furthermore, that the axiomatization uses the predicates type, value,
and so on.  (Again, via the argument to the keyword.)

A frame-based system, on receiving the file, assuming that it
recognized the keywords :frame-header and :frame-definition, would do
exactly the right thing -- ignore the material in the frame header and
collapse the material in the frame definition into a single defconcept
(or similar construct).  An FOL system would presumably recognize
neither of these keywords but would see that the clues being given
were nonsemantic ones and would therefore also do exactly the right
thing.  Furthermore, I can't see that it's any harder for the
frame-based community to settle on a few keywords (:frame-header and
:frame-definition in this example) and axioms (the contents of
:frame-header) than it would be for them to come up with a set of
special terms like "defconcept" and so on.  I would expect that other
nonsemantic information could be handled in a virtually identical

Does this address your concerns?