PROLOG-REQUEST@SUSHI.STANFORD.EDU (Chuck Restivo, The Moderator) (08/10/87)
PROLOG Digest Monday, 10 Aug 1987 Volume 5 : Issue 57
Today's Topics:
Query - FBRL & Multiple Copies of a Clause,
----------------------------------------------------------------------
Date: 5 Aug 87 16:18:59 GMT
From: decvax!dartvax!uvm-gen!emerson@ucbvax.Berkeley.EDU
Subject: FBRL in Prolog
Does anyone know of any FBRL's written in Prolog or that support
logical inference? I know HSRL (from Carnegie-Mellon) and KRYPTON
(from XEROX PARC) have a logical basis to them, but both are written
in LISP.
I am currently writing a FBRL interpreter embedded in C-Prolog, and
would like to ''compare notes'' with other such systems, if they're
out there.
I would also appreciate any thoughts on the implementation of frame
theory in Prolog.
Thanks in advance,
-- Tom
------------------------------
Date: Sat, 8 Aug 87 00:54:28 EDT
From: Tim Finin <tim@linc.cis.upenn.edu>
Subject: FBRL
You may want to start by looking at Pat Hay's paper "The Logic of
Frames" from the mid to late seventies. He gives a logical account
for the semantics underlying the basic ideas in FBRL's. The paper is
reprinted in Brachman and Levesque's book "Readings in Knowledge
Representation" published by Morgan Kaufmann (1985).
I can point you toward three things involving FBRLs in Prolog that you
may want to look at:
[1] WIth a group from RCA, I built a frame-based representation
language in prolog called PINE. We used it to build an expert system
for diagnosing faults in ATE equipment. It is described in:
FOREST - An Expert System for Automatic Test Equipment; Tim Finin, Pamela
Kleinosky and John McAdams; Proceedings of the First Conference on
Artificial Intelligence Applications; (IEEE), Denver, Colorado, 1984.
A somewhat longer version is available as
technical report MS-CIS-84-09, Dept. of Computer and Information Science,
University of Pennsylvania, Philadelphia PA 19104
[2] Arity Corp offers an expert systems building toolkit (written by
David Drager) which is based on a FBRL. It's written in Arity Prolog,
of course. It is really quite powerful. I'd characterize it as a
cross between EMYCIN and KEE.
[3] The AI research group at UNISYS's Paoli Research Lab has been
using a FBRL implemented in Prolog to build many of their expert
systems for quite some time. There system is called KNET and is
similar to KL-ONE. An early reference is:
KNET - A logic Based Associative Network Framework for Expert
Systems"; Freeman, M., L. Hirschman and D. McKay; SDC, A Burroughs
Company; technical memo LBS 12; Sept. 1983.
I believe that there are several descriptions of it in the open
literature, but I'm not sure where they can be found.
-- Tim
------------------------------
Date: Fri, 7 Aug 87 09:53:27 EDT
From: Tim Finin <Tim@linc.cis.upenn.edu>
Subject: multiple copies of a clause in the DB
I'm studying various ways to extend Prolog's simple model of the
database (e.g. a flat, global collections of clauses) to a richer
hierarchical one with inheritance. I am trying to decide whether to
allow multiple instances of a clause in a resulting database view.
Most Prolog implementations, at least those descendant from DEC-10
Prolog, do allow the database to contain two identical clauses. Most
of the non-Prolog logic programming languages that I am familiar with
do not. I am interested in discovering what use, if any, people have
made of the ability to assert multiple copies of a clause into the
database.
I, for one, have never found a use for this in practice. In fact, it
has only effected my life by being a source of bugs. It is easy
enough to accidentally get multiple copies of a clause in the database
by consulting a file instead of reconsulting it or by defining the
same predicate in two different files. This can easily mess up your
program unless you use a rather pure logic programming style which
doen't depend on the order in which the clauses are stored in the
database.
Has anyone out there found a good use for this Prolog "feature"?
-- Tim
------------------------------
Date: 8 Aug 87 15:30:10 GMT
From: Saumya Debray <debray@arizona.edu>
Subject: Multiple Copies of a Clause in the DB
In my view, in this case the underlying implementation should provide
something that focuses on efficiency, without taking away from the
user the flexibility of imposing additional constraints if he so
desires. If I don't care about the presence of duplicate clauses, I
shouldn't have to pay the price of checking for duplicates; on the
other hand, if I do care about duplicates, it's easy enough to extend
"assert" to take care of this, e.g.:
my_assert((H :- B)) :- clause(H,B) -> true ; assert((H :- B)).
my_assert(Fact) :- clause(Fact,true) -> true ; assert(Fact).
Since "consult" is basically a read-assert loop, the analogous
extension of "consult" to "my_consult" is straightforward.
Such an approach is flexible enough to handle stronger notions of what
constitutes "redundancy" in the database as well, e.g. if I wanted to
ensure that only those facts were asserted that were not provable from
what's already in the database, I'd write something like
my_assert(X) :- not(X), assert(X). [*]
Of course, with this "my_assert" is no longer guaranteed to terminate,
but that's the user's problem.
[* This only works for ground facts, of course, but you see what I'm
getting at.]
In summary: language constructs should be designed so that (i) users
don't have to pay for features they don't use; and (ii) users should
have the flexibility of extending the basic language features to do
what they want without undue suffering.
-- Saumya Debray
------------------------------
End of PROLOG Digest
********************