XPost: comp.lang.lisp, comp.lang.prolog   
   From: bear@sonic.net   
      
   Martin Sondergaard wrote:   
   >   
   > S White wrote :   
   >   
   > > Hi,   
   > > Just wanted to ask some advice. My plan is to research the area of AI   
   > > and law, specifically by developing a prototype for decision support   
   > > system adjusted to particular legislation etc. As i'm a lawyer rather   
   > > than a technician i am not yet that skilled in the area of ai   
   > > programming but hopefully i'll improve. The main question is what   
   > > language (prolog or lisp) should i use to start the work? What i   
   > > mainly want to do at the moment is to create a program with which you   
   > > can converse in natural language and "build upon" it until it reaches   
   > > rather high sophistication. When I achieve a program capable of rather   
   > > general conversation (and also know more about ai) i plan to add the   
   > > legal reasoning part. What is your suggestion on how to go about this?   
   > > (It's a four year project so i know this wont happen overnight).   
   > > Ultimately i want to complement the program with some kind of good   
   > > interface (possible face with lip sync / speech synthesis).   
   > >   
   > > Regards,   
   > > S   
   >   
   > This is a very ambitious project.   
   > Even though you have allowed yourself 4 years, I don't know if you can do it   
   > in that time, because creating a program that can converse in natural   
   > language is extremely difficult.   
      
   I think you may be setting a much higher goal for the intelligence   
   of the AI than the original poster.   
      
   It's not hard to build a chatterbot.  If you restrict yourself to   
   patternmatching on the input and selecting and outputting a canned   
   response, you can write the "engine" in a few weeks and then, in   
   about six months of reading logfiles and debugging, you can create   
   something that has pretty good fluency.  It won't know what people   
   are saying, and it won't actually be much smarter than grass, but it   
   will have a bundle of linguistic responses and reflexes that make it   
   seem superficially capable.   
      
   Such systems are popular as "toys" like eliza, but they are capable   
   of being useful as desktop references and natural-language guides   
   through a tightly-organized domain of knowledge.  I have built such   
   useful systems professionally, in fact (and would cheerfully do it   
   again if someone would like to hire me. :-) ).   
      
   Now, if you actually want it to parse English and represent knowledge   
   in some useful, internally-accessible format and know what someone   
   said, and access a database and use its knowledge of english grammar   
   and vocabulary to plan and output its own sensible responses, that's   
   a whole different kettle of fish - at a wooly guess, *that* job is   
   at least two orders of magnitude longer and three orders of magnitude   
   harder.   
      
   > I'm working on such a project myself.  But I've been working on this project   
   > for many years, and I may well be working on it for the next ten years too.   
   > Natural Language Processing is not easy.   
      
   Heh.  Me too.  I got tired of just building "useful chatterbots" at   
   work and undertook a personal project to build the best handling of   
   language I know how to do.  We should compare notes sometime.   
      
   > I recommend that you use Prolog rather than Lisp.  Prolog is said to be   
   > better for NLP than Lisp.  Among other reasons, it has something called   
   > "DCG grammar" features.  (In other words it has facilities for parsing   
   > English sentences, to find out the grammatical structure of sentences.)   
      
   I'm using a Lisp, but that's probably just because I happened   
   to learn it first and I'm more comfortable with it.  Prolog is   
   absolutely great for pattern-matching among a huge number of   
   possibilities - which, basically, is what most parsing algorithms   
   wind up doing at some point.  If you think you can prioritize   
   matching work better than prolog's native rule-matching engine,   
   you may want to use a different language.  If not, definitely   
   do it in prolog.   
      
   I'm using hidden markov models to try to predict the best   
   grammar rule to try next and the most likely partial parse   
   to try it on; we'll see if the gain is worth the overhead   
   and the coding sweat.  It may turn out that I should have   
   just used Prolog.   
      
   > Torbjorn Lager wrote :   
   > > You seem to think that creating a "program with which you can converse   
   > in natural language" is simpler than creating a program that can do   
   > legal reasoning. As a computational linguist, I believe it is rather   
   > the other way around. Since you are a lawyer my advice would be to   
   > start with the legal reasoning part.   
   > <   
   >   
   > I agree with Torbjorn.  Designing a program that can have a conversation is   
   > difficult.   
      
   Well, ELIZA's not particularly difficult.  And an ELIZA-oid program   
   with 1500-2500 pattern/response pairs can actually provide pretty   
   good coverage of a narrow subject area even though it's not much   
   smarter than grass.  It sounded like the OP might be satisfied with   
   a reference system rather than something actually capable of   
   comprehension and legal reasoning; if so, it's achievable.   
      
   > You can then build up on this program, to give it more legal knowledge, and   
   > more complex behaviour.  If you wish, and if you have the time, you can add   
   > NLP features to it, so that the user can enter simple sentences which the   
   > Expert System responds to.   
      
   Absolutely the lifeblood of any program that handles natural language,   
   or any expert system of any kind really, is logfiles.  You have to   
   see how it does on inputs, identify where it's making mistakes, and   
   go back and fix it.  Every solution will cause it to make different   
   (usually more subtle) mistakes, until you get to a point where the   
   mistakes are either more subtle than you can see, or more subtle than   
   the mistakes it would make if you implemented the only "solutions"   
   your design allows.   
      
   Then you decide whether it's "good enough" for whatever your actual   
   purpose is.  If it is, you call its behavior correct and shrink-wrap   
   it.  After that, if you're satisfied with your design, you start on   
   another with a different set of subject matter, or if you're not, it   
   means you've learned something about the limitations of your design,   
   so you start on a new one with a better design.   
      
   I don't mean to make it sound hopeless; it's just the natural cycle   
   of AI projects in general.  But it has to be understood that the   
   process is driven by mistakes, and it has to be understood that if   
   the domain of knowledge is at all hard (natural language and legal   
   reasoning both easily pass this test) there will never be a day when   
   the system makes no mistakes.  If you are very good, there may come   
   a day when it makes no more mistakes than you.   
      
   No one has ever been that good yet with natural language.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)