RelEx2Logic rule engine not handling multi-conditional rule

[williampma]

Looks like it's better to set a separate issue for each problem.

If you enter the sentence "I gave him an offer he cannot refuse.", RelEx correct generate the following relations:

_iobj(give, him)
_obj(give, offer)
_subj(give, I)
_obj(refuse, offer)
_subj(refuse, he)

However, RelEx2Logic rule engine produced:

(SVIO-rule "he" (get-instance-name "he" "he@a6c2b97c-2dee-447b-a471-c27176a3c1f4" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")) "give" (get-instance-name "give" "gave@f0a5790e-e55d-498e-83bb-a6f8838a79fe" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")) "offer" (get-instance-name "offer" "offer@6eb30967-95ac-48db-a0c8-ffa3c319e1a9" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")) "him" (get-instance-name "him" "him@aa3c1ae7-745f-472b-8f33-d708be19f8a0" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")))
(tense-rule "give" (get-instance-name "give" "gave@f0a5790e-e55d-498e-83bb-a6f8838a79fe" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")) "past")
(det-rule "give" (get-instance-name "give" "gave@f0a5790e-e55d-498e-83bb-a6f8838a79fe" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")) choose_var_name "an")
(negative-rule "give" (get-instance-name "give" "" (ParseNode "sentence@de7a5938-6d91-4c62-93cb-8366071dd995_parse_2")))

where the SVIO-rule produced "he give offer", because there are multiple _subj relations and the engine is not distinguishing between them (The negative-rule's "give" not having UUID is a separate but slightly related problem).

I believe this issue should be fixed first before tackling the constant/variable problem because this issue requires changing the algorithm for going through the Criteriums and might overwrite the other fixes.

[linas]

FWIW, accidentally matching against multiple instances of subgraphs that just happen to be present is one of the joys and difficulties of working with pattern matching, in general. Accidental matches can be avoided by providing "not" rules or various sorts.

This is one reason I keep burbling about pattern matching: it seems like a really easy task, at first... then you start hitting speed bumps.

[linas]

This is closed why? Is it fixed? no longer an issue? was it due to a misunderstanding?

[linas]

oh, never mind. it was fixed by pull request #37