Hi Jason, I finally got access to the pdf file that you listed (I had a problem getting there this morning).
>From what I see (in the paper from a very quick read), it would appear that your Natural Language Parser (NLP) would have to determine certain essential pieces of information in order to determine how to "match" this information to (JESS) rules and then package this up as "parameters" for the rules to reason over. This suggests that the problem comes in two pieces: (1) trying to determine (through parsing) what subject area (theme) the user is interested in and what is the relevant information for this area of concern, and (2) building a rule based system that corresponds to reasoning in this theme. As I mentioned above, one of the challenges would be to deal with the Presentation Service saying "I have a question" and the Inferencing Service saying "I have an answer, let's see if they match". I come across this frequently with clients wanting to build Rule Synthesis (or Authoring) systems. My approach is to use parameterized rules in the Inferencing Service and send the parameters as a bundle from the Presentation Service in such a way that the rules can match on some Parameter Object that fits the proper rule. It is kind of abstract when it is first seen, but it really isn't that difficult to do. I think the biggest challenge is in the NLP area where the machine needs to "learn" how to interpet the input. I am a YACC/LEX afficionado and I have even dabbled with Object-oriented, rule-based parsing but I have never had occasion to do NLP work (except for voice-activated systems which really are grammar based). If I had to do NLP work, I would probably lean towards YACC/LEX, rule-based parsers (which opens the AI "learning" door). Sounds very interesting though - Good Luck !!!! Rich Halsey ----- Original Message ----- From: "Jason Morris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 05, 2004 10:44 AM Subject: RE: JESS: Re: Restricted Language Query/ Natural Language Parsing in Jess > Hi Rich , > > Sort of. :-D > > If you look at the article in the link, you'll see how the researchers > approached the problem. Basically, I would like to start a Jess application > (that follows the Tax Advisor pattern, but isn't a Tax Advisor!) by allowing > the users to enter a free-text problem statement -- like when you tell your > doctor "where it hurts". The doctor can then begin to make inferences about > what type of problem you may have by parsing your input and pattern-matching > it to syntactically similar, "pre-parsed phrases" that share the distilled > semantics of the original input (if that makes sense), and then ask more > leading questions to heuristically home-in on the solution. > > As an example, in a typical BNF production, I might have a definition > > <problem_statement>::= <subject><verb><end-mark> so that a > <problems_statement> is composed of a the "non-terminals" > <subject><verb><end-mark> in that order. > > And I might have a vocabulary like > > <subject> -> I | You | We > <verb> -> ran | jumped | cried > <end-mark> -> . | ? | ! > > For all the possible combinations of these non-terminals and terminals (all > productions), I'd have to construct a rule to deal with that production. If > I understand the article right, what they did was to map the set of all the > synonyms of each of the non-terminals to a "key", and after doing this they > composed phrases of these keys to store the generic semantics of the input, > thereby collapsing the number of patterns for which they need to store a > meaning. > > I just thought that it was a novel approach instead of parsing the string by > brute force and trying to process the results with a gazillion rules. > > Hope that clarifies a bit. > > Regards, > > Jason Morris > ------- > Morris Technical Solutions > [EMAIL PROTECTED] > www.morristechnicalsolutions.com > fax/phone: 503.692.1088 > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Rich Halsey > Sent: Thursday, February 05, 2004 4:06 AM > To: [EMAIL PROTECTED] > Subject: JESS: Re: Restricted Language Query/ Natural Language Parsing > in Jess > > > Hi Jason, > > In trying to reduce the description of your problem, I came up with the > following: > > Use a Natural Language front-end for the user to interact with a rule-based > Tax Advisor where the rules derive a solution to a query based on data > derived from a free form input. > > Does this sound even close to what you want to do ?? > > Rich Halsey > > ----- Original Message ----- > From: "Jason Morris" <[EMAIL PROTECTED]> > To: "Jess-Users" <[EMAIL PROTECTED]> > Sent: Wednesday, February 04, 2004 7:07 PM > Subject: JESS: Restricted Language Query/ Natural Language Parsing in Jess > > > > Hi All, > > > > Sorry for the long post, but this is an esoteric question... > > > > I am interested in adapting the Tax Form Advisor (using it almost like a > OO > > design-pattern) by adding a component that can reason about information > > drawn from natural-language input as well as using restricted answers to > > hard-coded questions. To make the parsing problem more tractable, I began > > thinking of different ways that I could derive meaning from various input > > strings without coding a huge parsing engine from scratch or writing > > hundreds of extra rules. I read a lot of parsing theory and experimented > > with various BNF syntaxes, but quickly ran into trouble as the language > grew > > and the rules became more complex. Since my background is in mechanical > > engineering, I tried to draw parallels with what I already know. > > > > In fluid mechanics, there is the theory of non-dimensional parameters > > whereby a complex functional equation in m variables and n dimensions can > be > > reduced to (m-n) dimensionless parameters, which should be theoretically > > easier to manipulate. I reasoned: why couldn't I attempt to do the same > > thing with words -- in other words, treat the input string as function of > > tokens having a certain "dimension" or membership in semantic subsets, and > > then attempt to "normalize" the string to fit a stored semantic pattern > that > > would have meaning to Jess. Theoretically, this would significantly cut > > down the number of rules that I'd have to write to handle various inputs, > > even ambiguous ones, while letting the user type away to describe the > > initial problem input. > > > > Alas, it seems that my idea was anticipated (see pg.2): > > http://www.amia.org/pubs/symposia/D005310.PDF > > > > However, does anyone have any good suggestions as to how to implement this > > approach in Jess? > > > > Thanks! > > > > Jason Morris > > -------- > > Morris Technical Solutions > > [EMAIL PROTECTED] > > www.morristechnicalsolutions.com > > fax/phone: 503.692.1088 > > > > -------------------------------------------------------------------- > > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > > (use your own address!) List problems? Notify [EMAIL PROTECTED] > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
