From: Warren Lucas
Subject: Experience with Harlequin Knowledge Works
Date:
Message-ID: <389F3F2C.35E6F168@byu.edu>
(1) I anticipate upgrading to the Enterprise version of LispWorks to
have access to Knowledge Works. Before doing so, I would be very
interested in the experiences of those who have used the system.
(2) Are there any good (convenient, efficient, ect.) options for
integrating forward chaining, backward chaining and rule representation
with an existing Lisp system, as is done in Knowledge Works? I am
really not looking to implement Knowledge Works look alike with new
code, but would be very interested in good options that would require
minimal effort to tie together. Any thoughts?
Thanks,
Warren
--
____________________________________________________
Warren K. Lucas
Assistant Professor
Department of Civil and Environmental Engineering
368 Clyde Building
Provo, Utah 84602
(801) 378-6234
·······@byu.edu
____________________________________________________
From: David Bakhash
Subject: Re: Experience with Harlequin Knowledge Works
Date:
Message-ID: <cxjhffj6t69.fsf@engc.bu.edu>
Warren Lucas <·······@byu.edu> writes:
> (2) Are there any good (convenient, efficient, ect.) options for
> integrating forward chaining, backward chaining and rule representation
> with an existing Lisp system, as is done in Knowledge Works? I am
> really not looking to implement Knowledge Works look alike with new
> code, but would be very interested in good options that would require
> minimal effort to tie together. Any thoughts?
Knowledge Works is very general. Not every problem is, though. I
have some experience, with it, and found that it was easier to
re-implement everything, which wasn't easy either. I think the
problem with KW, and that general class of algorithms is that
optimization (in solutions) is not really considered. And it is very
hard to consider it in the general case.
Not knowing exactly what your application is would leave me to say
the following, not-very-informative things:
1) KW is not that simple. It will take a fair amount of time to get
up to speed with it.
2) It's generality can cost you, performance-wise
The reason I liked it a lot, though, in the beginning was that LW has
such an amazing CLOS ODBMS that interfaces with whatever RDBMS you're
using, provided it has a SQL interface. I got a lot of mileage out of
that. But if you're not using a SQL database, then It's not really a
win.
Anyway, I was still able to use LW's CLOS/SQL interface in my non-KW
implementation.
dave
On 08 Feb 2000 20:50:06 -0500, David Bakhash <·····@bu.edu> wrote:
> Warren Lucas <·······@byu.edu> writes:
>
> > (2) Are there any good (convenient, efficient, ect.) options for
> > integrating forward chaining, backward chaining and rule representation
> > with an existing Lisp system, as is done in Knowledge Works? I am
> > really not looking to implement Knowledge Works look alike with new
> > code, but would be very interested in good options that would require
> > minimal effort to tie together. Any thoughts?
>
> Knowledge Works is very general. Not every problem is, though. I
> have some experience, with it, and found that it was easier to
> re-implement everything, which wasn't easy either. I think the
> problem with KW, and that general class of algorithms is that
> optimization (in solutions) is not really considered. And it is very
> hard to consider it in the general case.
Hi David,
To be fair, KW adds rule-based programming to CLOS in the form of OPS and
Prolog. Neither of these languages is intended to provide optimization
solutions directly. Instead they lift you up another horizontal level. Building
some optimizing applications in OPS and Prolog and Common Lisp can be simpler
than Common Lisp alone, but it does depend on the application.
> Not knowing exactly what your application is would leave me to say
> the following, not-very-informative things:
>
> 1) KW is not that simple. It will take a fair amount of time to get
> up to speed with it.
Just to qualify this: KW is intended to be standards-based. It brings OPS and
Prolog to CLOS. So if you spend time learning e.g. KW's backward chainer then
much of what you've learned is general stuff that can be reapplied to freebie
Prolog-in-Lisp tools or native Prologs.
> 2) It's generality can cost you, performance-wise
In some sense I think this is a universal truth, but as usual you get to trade
initial application speed for development time. However, KW seems to
out-perform other commercial Lisp-based expert system shells that it replaces
at customer sites.
> The reason I liked it a lot, though, in the beginning was that LW has
> such an amazing CLOS ODBMS that interfaces with whatever RDBMS you're
> using, provided it has a SQL interface. I got a lot of mileage out of
> that. But if you're not using a SQL database, then It's not really a
> win.
>
> Anyway, I was still able to use LW's CLOS/SQL interface in my non-KW
> implementation.
Yes the CLOS/SQL interface is dandy.
__Jason